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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
