On Sat, 2017-04-08 at 15:01 +0200, Dirk Bächle wrote: > Hi Russel, hi Jean-Baptiste, > > > thanks a lot for starting and chiming in on this topic, which I think > is > an important one. When I read Russel's other (opinionated) post > about > how D is likely to gain more ground than Rust/Python in the future, > I > asked myself: What can we possibly do to support this? How can we be > ready for this stream of development if it should really happen in, > let's say, 2019?
Much of my writing is opinionated, I have now tried to mark where that is the case. :-) > > So I'm all ears for trying to get better support for D into the > SCons > core. For me the main question, referring to your subject of "..., > not > sure what to do", is: What exactly would have to be done to make > SCons > the canonical choice as build system for D? Dub is for the short and medium term always going to be the default choice for people to build D code. Like Cargo it has its good, and indeed excellent points. However some choices Dub makes, which Cargo makes differently, mean that Cargo works and Dub has some serious problems. > > Can someone (we together) compile a list of things that would have > to > get implemented and improved? Something along the lines of: > > > - We need recursive Globbing. (Full support of Ant-like syntax) > > - We need to be able to handle required Libraries as leaf nodes in > the > dependency tree, even if they reside in a remote > repository/artifactory. > > - We need to be able to cache the contents of those libraries > locally > (in case of being offline). > We need to be able to do build by individual file compilation and then explicit linking *and* we need to support all source at once compile and link in one go. We need to support getting source from a central repository and compiling that ready for being linked to during project compilation. We need easy management of debug, optimiseddebug, and release configurations. We need to pinch lots of nice ideas from Meson! Meson takes a lot of ideas from SCons and Waf about specification using a nice DSL, and the configure/build split idea from Waf and CMake. Meson is a Ninja configuration system as CMake is a Make or Ninja configuration system. The big win for Waf and SCons over Meson and CMake in my opinion is that the DSL is Python code and not a DSL that is parsed as with Meson and CMake. > (I'd like to continue this list but my knowledge of D is obviously > restricted...so feel free to add "- We need more SCons core devs to > be > proficient in D development." to the list above ;) ) We need more people who know and use D actively involved. :-) Ditto Fortran and C++17 I guess. C++20 will likely have modules, they did not get into C++17. So SCons is going to have to be able to deal with that. i.e. the whole #include system will be going. But eventually, this is just an early warning. > > Then we should have a look at this list, and decide which points are > technically feasible and "in line" with SCons' basic design > principles. > We can probably also identify a number of features that are not only > helpful for D...but other languages/toolchains as well. Those should > get > the highest priority perhaps...but I also believe that any kind of > development in the core sources, even if strictly D-oriented, is > good > for the project. My feeling is that the hardest problem is going to be getting and building dependencies, the rest just requires people writing test cases and fixing the code that they break. The "all source at once" is I think just a question of creating a ProgramAllAtOnce to augment the Program. It just creates a single executable node with no object nodes in the tree. Shouldn't be a problem. I see no reason not to use Dub to get the source. Or if we do not want to make use of an external program use the Dub API directly from newly written code. I prefer the latter myself, but I know some packages (such as Unit-Threaded) seem to require the Dub executable – I haven't sorted out why yet. I suspect the biggest hurdle is going to be that there are three D compilers leading to a similar problem as the C and C++ compiler selection. In the end though it is down to effort and maintaining non-zero progress. -- 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
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
