All at once compiling, and SCons direction

Russel Winder <[email protected]> Tue, 11 Apr 2017 06:17:23 +0100
Newsgroups	gmane.comp.programming.tools.scons.devel
Message-ID	<[email protected]>
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

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc (application/pgp-signature, 833 B)