On Tue, 2017-04-18 at 07:34 +0000, Alex via Digitalmars-d wrote:
> 
[…]
> I know, I have been using your work in SCons to build in this mode since it was first available.

Excellent. :-)

[…]
> > > 
> 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.

SCons should be immune to whitespace changes, but actual reformatting is likely to be a change.

Hummm… it is not clear in my mind just now whether that dependency is
build into the SCons build DAG. Whilst the C and C++ builders go to
great lengths to deal with the #include dependency tree, I am not sure
the D tools parse the D source import dependency tree. It probably
should, but just now – I believe – it is just module by module
compilation. If there are API changes then SCons will not follow that
through for D codes.

> 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.

I have never trodden the .di file path and so the SCons tools do not generate them. A flag could easily be added so that an emitter of the builder could generate the .di as well as the .o file. The tools are not set up for that as yet, but it could be done.

Being sent small projects as test cases to drive adding features is likely the best route. Feel free to send in issues on  https://github.c om/russel/SCons_D_Experiment

[…]
> 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.

It maybe that the missing link here is that the D builders currently do not have emitters. With an emitter added doing the .di as well as .o files should be very straightforward – but maybe not easy.

[…]
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, Apr 18, 2017 at 07:34:34AM +0000, Alex via Digitalmars-d wrote: [...]
> 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.

This is not a problem if you use env.Decider('content'), in which case the worst that will happen is that the module with the whitespace / unittest change will be recompiled, but everything else that depends on that module won't be touched because the object file will have the same content as before.


> 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 is not workable for D code that uses a lot of templates. In my own projects I never use .di files because it suffices to import the .d file directly.  In the D world, generally the only time you'd use .di files is (1) interfacing with proprietary libraries, or (2) interfacing with C/C++ code (but even in this latter case, it's common practice to simply declare C/C++ functions in extern(C) or extern(C++) blocks inside a .d file, rather than have a .di file). It's pretty unnatural to use .di files anywhere else in the typical D project.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Tuesday, 18 April 2017 at 00:14:40 UTC, Andrei Alexandrescu wrote:
> On 4/17/17 6:58 PM, Atila Neves wrote:
>> On Monday, 17 April 2017 at 17:51:33 UTC, Russel Winder wrote:
>>> Just in case anyone gives a ####:
>>>
>>> I have submitted a pull request that adds ProgramAllAtOnce as a builder in the dmd, ldc, and gdc tools of SCons. This does an 'all at once' compilation in a single compiler instantiation, unlike the standard module at a time compilation and then link the program. There are lots of arguments about whether "all at once" is at all useful, I have added it simply because it is the only way Unit-Threaded works.
>> 
>> It's the only way __traits(getUnitTests) works. Unfortunately. I'm just going to fix that dmd bug myself.
>
> Thanks!! -- Andrei

https://github.com/dlang/dmd/pull/6727

Getting it past the autotester was the hardest part of that odyssey!

Atila

On Tuesday, 18 April 2017 at 00:14:40 UTC, Andrei Alexandrescu wrote:
> On 4/17/17 6:58 PM, Atila Neves wrote:
>> On Monday, 17 April 2017 at 17:51:33 UTC, Russel Winder wrote:
>>> Just in case anyone gives a ####:
>>>
>>> I have submitted a pull request that adds ProgramAllAtOnce as a builder in the dmd, ldc, and gdc tools of SCons. This does an 'all at once' compilation in a single compiler instantiation, unlike the standard module at a time compilation and then link the program. There are lots of arguments about whether "all at once" is at all useful, I have added it simply because it is the only way Unit-Threaded works.
>> 
>> It's the only way __traits(getUnitTests) works. Unfortunately. I'm just going to fix that dmd bug myself.
>
> Thanks!! -- Andrei

So... I have, and it's languishing waiting for someone to merge it. Or just to give me a LGTM, I'd merge it myself then.

https://github.com/dlang/dmd/pull/6727

Atila