In the D community there is a low-volume, very long running debate about whether D should be compiled module by module (a module is a file in D just as in Python), package by package (slightly difference concept to Python, but structurally the same, a package is a collection of related modules), or all source at once. CMake, Meson, and SCons all support module at a time, or you use your own command line. Dub always does all source at once.
For Chapel, I believe you always have to do all source at once, but I need to check this. As far as I know, whilst SCons always does file-by-file and then link (because of the C, C++, Fortran heritage, it does not stop builders doing all at once it's just that no-one has done this. Chapel is heading towards a Rust/Cargo type dependency/build system. Since Rust folk all just use Cargo, SCons, CMake, Meson do not have any language specific support. Nor are they likely to I suspect given the way these things generally pan out. Thus I wonder is there is any point in trying to support Chapel. It's a relatively small community, and SCons doesn't have the core code to handle dependencies in the Maven, Bintray, Artifactory, Herd, Cargo, Conan, Dub sense, i.e. a library of source or pre-compiled held centrally to be downloaded as part of the build. My feeling is that if Conan takes off, SCons must have integral support for it. I have no idea if CMake and Meson are planning anything. Clearly Maven and Gradle already do this for JVM artefacts, Cargo for Rust, Dub for D. Given SCons is supposed to support D, it now needs a story regarding the Dub repository. Dub the command has a dependency specification of name and version number (bounded or unbounded ranges) in the project specification file. It then gets the source from the Dub repository files it away and then compiles it to create the linkable library, or executable. Cargo does roughly the same sort of thing but it also allows an arbitrary Git repository to be accessed as a dependency. There is also the question of whether a dependency management system should allow for arbitrary DVCS repositories to be used as well as things from the central repository. Experience from Rust/Cargo and Ceylon/Herd shows that having this increases community activity. Go not having a central resource is I think missing a trick. There is a level of confidence about a curated central store that is very helpful. So should D support in SCons also support Dub, or go further than Dub. Dub does the wrong thing with compilation of dependencies, it adds the compiled into the source filestore cache in ~/.dub, which is just wrong. Cargo keeps only source in the source filestore cache, all compilation happens into the project filestore which is the right thing to do, particularly for keeping debug and release build going at the same time. The question is then whether a D specific infrastructure should be built, or whether this should be seen as an experiment for a more generalist solution? Is there a future for a generalist solution, or would it just be wasted effort? -- 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
