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
