Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]

[Jonathan M Davis]

On Wednesday 13 July 2011 06:53:28 Russel Winder wrote:
> On Tue, 2011-07-12 at 22:28 -0700, Jonathan M Davis wrote:
> [ . . . ]
> 
> > From previous discussions, it seems that one of the primary reasons for
> > having a D build tool in many people's minds is to also handle package
> > management of D libraries (like Haskell's cabal or rubygems for ruby).
> > And as great as cmaked, scons, gradle, waf, and other such tools may
> > be, they don't do that.
> 
> Go is currently using Make for this -- they have a structured Makefile
> hierarchy that handles most compilation and linking in the context of a
> rigidly enforced filestore structure, and goinstall for bringing in
> packages from outside into the filestore hierarchy.  It is a bit
> primitive at the minute, but is being worked on and rapidly improved.
> 
> Go actually has a plethora of build tools, include a couple of
> SCons-based ones, most of which are falling by the wayside.  I think the
> effort expended doing this has not been a waste as information is being
> generated that is adding to the pool.  I think they will replace the
> Makefile system shortly with one of the tools, possibly GoBuild, but I
> can't remember exactly.
> 
> Haskell and Ruby both have inward looking approaches -- to put it
> bluntly (at the risk of causing offense to some), Haskell build only
> cares about Haskell source and Ruby build only cares about Ruby source.
> Almost by definition D has to live in a mixed C, C++, Fortran, D
> universe, so this has to be an issue from the outset.
> 
> I agree with the premise that package management must be a core part of
> the build management, but I disagree that Gradle, SCons, and Waf cannot
> handle this.  They cannot handle this today true, but in the same way
> that there is currently no system that does it properly as yet.  So I
> would suggest that package management is currently a "green field"
> problem that can be handled by a D-specific tool or one of Gradle, SCons
> or Waf.

Feel free to propose whatever you'd like for a D build system (be it something 
entirely new or an improvement of an existing build tool). I'm just pointing 
out that one of the primary reasons that a number of the people on this list 
want a build tool is to handle package management of D libraries, so whatever 
solution you propose should incorporate that or a lot of people aren't going 
to be all that interested in it or will at least see it as inferior to another 
solution which does incorporate package management.

- Jonathan M Davis