D, SCons, Dub

[Alex via Digitalmars-d]

On Tuesday, 18 April 2017 at 06:51:51 UTC, Russel Winder wrote:
>> I have been trying to do the opposite with scons - incremental 
>> builds. In c++ the .h and .cpp files allowed the compilation 
>> from many edits to be limited to one translation unit.
>
> Per module compilation then linking is the default for the 
> Program builder in SCons, that is already there and has been 
> for over a decade.
>
I know, I have been using your work in SCons to build in this 
mode since it was first available.

>> One thing people are often confused about is whether 
>> everything needs to be in the header (or di file).
>
> Uuurrr… there is no separation of header and code in D, just 
> modules. And packages. SCons currently has no "per package" 
> builder. I guess I need to add this.

I realise there are no headers, that is the problem. SCons can't 
tell whether a change to a module affects the interface, only 
affects the implementation or only affects a unit test. This 
means everything that imports a module is recompiled on every 
edit, even if only the unit test was modified, or a formatting 
change was made.

I am not suggesting the D way is bad compared to C++, I am 
suggesting we can have the best of both worlds by automatically 
generating 'headers' or .di files from modules. Then having 
dependent modules read only the .di file instead of the .d file.
This way SCons won't recompile dependencies unless necessary. 
This is the main purpose of using SCons (perfect incremental 
builds) which is largely defeated currently by D.


> Currently there is no explicit handling of di files in SCons.
I know, I have been working through the guts of SCons for (a 
little bit too long to mention)  trying to make it both output 
two products with proper dependencies (.o and .di) and to find 
the di files correctly. SCons seems to have an ability to find 
the original .d files in the project even if the compiler can't.

> If you can come up with a small project that exhibits the 
> problem you need solved, I can add it as a test case in the 
> SCons system thereby creating a need for a fix.
>
Thanks for that kind offer Russel, I will make a minimal example 
project.

> (Tests in SCons for the tools are end-to-end tests, so need a 
> project
> exhibiting a problem.)

OK.