SCons support for D

Russel Winder russel at russel.org.uk
Wed Dec 7 06:03:02 PST 2011


On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote:
[...]
> I'm suggesting that the current multi-pronged approach to providing a
> workable build system is hampered by the multitude of directions and
> could benefit from some initial discussion, consensus and design.

OK.  It is a valid point, effort is being diluted.  On the other hand
various people prefer different systems, so I am not sure there is any
constructive point in dictating the "one true build system".  If there
were one that gained a majority support votes then it could concentrate
available effort.

[...]
> I agree that it would be good to use a tool with support for multiple
> languages & platforms.  I was trying to point out that the multitude of
> options is potentially harmful.

Or an opportunity?

D is trying to supplant C, C++, Fortran and Python.  D should therefore
be buildable with the same tools that people use with these languages in
order to provide the lowest possible barrier to entry to D of C, C++,
Fortran and Python programmers.  Not having to change build system but
simply to add to their current build system makes transition easier.

[...]
> Simple Ant scripts are easy, but XML is a very bad choice for a build
> system IMO 

XML was an interesting choice originally, but has been perverted beyond
sanity in the Ant context.  This is why I wrote Gant -- use all the Ant
tasks but not from the XML interpreter but from Groovy scripts.  The
idea cannot have been all bad as it inspired Hans Dockter to create
Gradle, and the Apache folk forked Gant to create the Groovy frontend to
Ant.

[...]
> 
> Not really what I was suggesting - I was hoping to discuss
> consolidating effort around a small set of tools, rather than the
> current state.

I fully appreciate the idea is to focus effort so as to avoid dilution.
With the effort available it is a good idea.  I am just not convinced
creating new tools from scratch is the right approach.

[...]
> > Do we work with a build framework that exists and already allows
> > serious build using D; or
> 
> Possibly.
> 
> > do we start from scratch with a new build framework that no-one can
> > use till something is ready?
> 
> Possibly (if necessary)
> 
> I thought it important to have a discussion first to determine the
> requirements and use cases, and concentrate effort rather than
> disperse it.

Having a full and frank exchange of views is an excellent move.  As long
as everyone stays friends!

Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen,
Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the
overall effect of a "focused on D" build tool, whether build from
scratch or over another framework.  Specialist per language build tools
lead to a ghettoization.  Even 5 mins looking at the Rake, sbt and
Leiningen situations make this abundantly clear.  Which is sad as there
are many good things about all of them.

If there effort to start from scratch with D to create the replacement
for Make, CMake, Autotools, as a general build framework, that is a
different issue.  But this is a big undertaking requiring DAGs, C
scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to
mention tool finders and toolchain builders.

My current prejudice is that SCons, Waf and CMake already have almost
all of this stuff already in place, so it is an incremental step to make
sure they work well with D (*).


(*) Though due to various bits of history, the project lead of Waf has
declared me persona non grata, so I cannot actually contribute to Waf
and its D support :-((  

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111207/0e76e969/attachment.pgp>


More information about the Digitalmars-d mailing list