D, SCons, Dub

[H. S. Teoh via Digitalmars-d]

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