Build [ was Re: Why Ruby? ]

Russel Winder russel at russel.org.uk
Sat Dec 11 01:44:01 PST 2010


On Sat, 2010-12-11 at 01:12 -0500, Nick Sabalausky wrote:
[ . . . ]
> I can definitely see in Ruby how the designer was trying for a "natural 
> language/thought-process" feel, but it just ends up feeling 
> sloppily-designed. I never feel completely confident that what I write is 
> actually going to get parsed as I intended. It's like playing with voodoo, 
> especially when you toss in the syntax-tricks that idiomatic-Rake uses. It 
> certainly gets the job done for what I'm using it for, but if there was a 
> DRake, I'd be using it instead.

I tried Rake some time ago when I decided that external DSL-ish Make
(whilst a huge revolution and revelation in 1978) had gone past it's
"use by" date -- GNU Make tries hard to cope but . . . Internal DSL, so
having the power of the programming language to hand, seem to be the way
forward.  Rake though seemed totally centred on supporting only Ruby
activity.  No real support for C, C++, Fortran, LaTeX, except "do it
yourself" stuff.  I then found Rant which was trying to replace Rake but
with proper infrastructure to have great support for C, C++, Fortran,
LaTeX.  Sadly the project died for lack of interest.  Conclusion:
anyone with sufficient interest in Ruby and "build" was unlikely to be
doing anything other than Ruby :-(  I then moved attention to SCons.
Python instead of Ruby, but lots, and lots of support for C, C++,
Fortran, LaTeX.  Actually too much support for C and C++, it is too
hardwired into the core of SCons.  Also there are some issued of speed.
Waf was originally a fork of SCons, but is now completely its own thing.
Waf is an Autotool replacement, where as SCons is a Make replacement.  I
end up using both, Waf in a project context and SCons where I need more
generality, no project structure per se.

Both SCons and Waf have support for D -- but both could do with more and
better usage, community and support.

Generally it seems that for any new language, those interested in build
have the knee jerk reaction of having to write a new build system.
Usually the build system has little generality, too focused on the
language of origin, and having lots of zealots.  The JVM-based-verse is
full of such things.  But let's leave them to it.

I would suggest that a dynamic language is the right platform on which
to create a build framework.  This would seem to rule out D as a
language for construction of build systems -- though SBT in Scala has
ploughed effectively this "static language as platform" furrow, so
maybe . . .

The Go community seems to have an unusually large supply of the "must
write a new build framework using this new language" folk, I seem to
count seven new build frameworks at the last count.  The Google folk who
are the core Go team have though stuck with Make -- which really seems
strange.

OK so what the purpose of this email:  I think it would be good to line
up behind one or two build frameworks and make sure they have seriously
good support for D build, especially given the relationship of D to C
and C++.  This would seem to indicate SCons and Waf from the current
batch, though I bet most people are still using Make.    But it is so
hard to provide "plugin tools" with make, especially compared to SCons
and Waf.

I am assuming that people are not going to vote in favour of Autotools
being the one true build framework for D ;-)

I should stop writing here and open things up to the floor . . . 
-- 
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/20101211/2cc9d338/attachment.pgp>


More information about the Digitalmars-d mailing list