This is a self-contained and really fun project:

https://issues.dlang.org/show_bug.cgi?id=14654

It requires an understanding of how rdmd currently works (<1KLOC in a single module!) and is of huge impact.

Who'd want to get into it? I would if I didn't already have std.allocator to have fun with.

(Speaking of which: regions that grow upwards or downwards depending on stack growth direction for cache hotness, yum! http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html)


Andrei

On 2015-06-05 18:15, Andrei Alexandrescu wrote:
> This is a self-contained and really fun project:
>
> https://issues.dlang.org/show_bug.cgi?id=14654

It looks like you want to support incremental compilation. Two questions:

* Is that possible? I know there has been some problems with this in the past, i.e. not all symbols were outputted to all object files

* Why rebuild a whole directory when it could only rebuild a single file?

-- 
/Jacob Carlborg

On 6/6/15 6:03 AM, Jacob Carlborg wrote:
> On 2015-06-05 18:15, Andrei Alexandrescu wrote:
>> This is a self-contained and really fun project:
>>
>> https://issues.dlang.org/show_bug.cgi?id=14654
>
> It looks like you want to support incremental compilation. Two questions:
>
> * Is that possible? I know there has been some problems with this in the
> past, i.e. not all symbols were outputted to all object files

Whatever the matters are, we will fix them.

> * Why rebuild a whole directory when it could only rebuild a single file?

Compiling several files at once is faster. The natural boundary is one package.


Andrei

On Friday, 5 June 2015 at 16:15:21 UTC, Andrei Alexandrescu wrote:
> This is a self-contained and really fun project:
>
> https://issues.dlang.org/show_bug.cgi?id=14654
>
> It requires an understanding of how rdmd currently works (<1KLOC in a single module!) and is of huge impact.
>
> Who'd want to get into it? I would if I didn't already have std.allocator to have fun with.
>
> (Speaking of which: regions that grow upwards or downwards depending on stack growth direction for cache hotness, yum! http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html)
>

My $0.02: any project large enough to care about if rdmd builds per package or not is likely to need a real build system anyway.

Atila

On 6/6/15 8:51 AM, Atila Neves wrote:
> My $0.02: any project large enough to care about if rdmd builds per
> package or not is likely to need a real build system anyway.

Integrating the strategy within rdmd will help make it popular and widespread. I recall Liran has had issues with build times but hadn't tried per-package builds because they weren't a common idiom. -- Andrei

On Saturday, 6 June 2015 at 15:54:39 UTC, Andrei Alexandrescu wrote:
> On 6/6/15 8:51 AM, Atila Neves wrote:
>> My $0.02: any project large enough to care about if rdmd builds per
>> package or not is likely to need a real build system anyway.
>
> Integrating the strategy within rdmd will help make it popular and widespread. I recall Liran has had issues with build times but hadn't tried per-package builds because they weren't a common idiom. -- Andrei

From the conversation I had with him, he wouldn't be able to use rdmd anyway. I understand the "the default should be per-package and encouraged" argument though. In which case I'd tell people to try reggae ;)

Atila

On 2015-06-06 17:38, Andrei Alexandrescu wrote:

> Compiling several files at once is faster. The natural boundary is one
> package.

Perhaps I misunderstand something. Why compile files that has not changed? I mean that rdmd should compile all files that has changed including its dependencies, no more, no less. It should compile all these files in one go.

-- 
/Jacob Carlborg

On Friday, 5 June 2015 at 16:15:21 UTC, Andrei Alexandrescu wrote:
> This is a self-contained and really fun project:
>
> https://issues.dlang.org/show_bug.cgi?id=14654
>
> It requires an understanding of how rdmd currently works (<1KLOC in a single module!) and is of huge impact.
>
> Who'd want to get into it? I would if I didn't already have std.allocator to have fun with.
>
> (Speaking of which: regions that grow upwards or downwards depending on stack growth direction for cache hotness, yum! http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html)
>
>
> Andrei

How can any of this work without a special object format that is
template aware?

On 6/6/15 11:47 AM, Jacob Carlborg wrote:
> On 2015-06-06 17:38, Andrei Alexandrescu wrote:
>
>> Compiling several files at once is faster. The natural boundary is one
>> package.
>
> Perhaps I misunderstand something. Why compile files that has not
> changed? I mean that rdmd should compile all files that has changed
> including its dependencies, no more, no less. It should compile all
> these files in one go.

Yah, that's the traditional C-style module-at-a-time approach. Somewhat paradoxically, for D it's faster to compile several files at once, even though not all were affected by the change.

So in the package-at-a-time approach if at least one module in a package is affected by a change, the entire package gets rebuilt.


Andrei

On 6/6/15 12:15 PM, Shammah Chancellor wrote:
> On Friday, 5 June 2015 at 16:15:21 UTC, Andrei Alexandrescu wrote:
>> This is a self-contained and really fun project:
>>
>> https://issues.dlang.org/show_bug.cgi?id=14654
>>
>> It requires an understanding of how rdmd currently works (<1KLOC in a
>> single module!) and is of huge impact.
>>
>> Who'd want to get into it? I would if I didn't already have
>> std.allocator to have fun with.
>>
>> (Speaking of which: regions that grow upwards or downwards depending
>> on stack growth direction for cache hotness, yum!
>> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html)
>>
>>
>>
>> Andrei
>
> How can any of this work without a special object format that is
> template aware?

It works; these are distinct concerns. -- Andrei