Dream package management system (Was: a cabal for D ?)

[Jacob Carlborg]

On 2011-04-03 08:55, Russel Winder wrote:
> On Sat, 2011-04-02 at 21:35 +0200, Jacob Carlborg wrote:
> [ . . . ]
>> I don't think it's the package manger's job to build the
>> application/library. The package manager operates on a level higher than
>> a build tool. The build tool is working with files, tracking
>> dependencies among files and building applications/libraries. The
>> package manager is working with packages, tracking dependencies among
>> packages.
>
> Haskell's Cabal has blurred the lines between package management and
> build in many people's minds, but it only succeeds when in isolation.
> As soon as there is a platform packaging system it is clear that build
> and packaging must be separate.  Though obviously you can get into
> JVM/Maven, and indeed Go, situations where again the lines get blurred.
>
> For something such as D which should have some ability to work with C
> and C++ libraries, keeping the separation is likely a better route.
>
>> I was planning to creating my own build tool that would be integrated
>> with the package manager. The package manager would use the build tool
>> to track the files making up the package. But other build tool would be
>> supported as well, not forcing anyone to use my build tool.
>
> Is there a need for a brand new build tool.  Are CMake, SCons and Waf
> not sufficient to the task?

This might not be fair, because I haven't used Waf, SCons or CMake very 
much, but I think they look too complicated. I would like a simple tool, 
I like dsss/rebuild it's a simple tool. You just put the file containing 
the main function in a configuration file and it just works.

> Clearly there are no perfect tools, there is always room for evolution
> and new things.  However the history in the JVM-related milieu and the
> Go arena, indicate that the knee jerk reaction of "we have a new
> language, therefore we must write a new build framework" leads to a lot
> of isolationism, creation of ghettos, and a lot of wasted effort.  Go
> has at least 6 brand new build frameworks, all of which were deemed
> necessary, and none of which have gained any traction -- the core
> development team are believers that Make is all that is needed.  Rake
> has gained little traction outside the Ruby community. Leiningen has
> little traction outside the Clojure community.  SBT has little traction
> outside the Scala community.  Gradle is getting significant traction
> across the Java and Groovy communities as it solves problems inherent in
> the wildly successful Ant and Maven frameworks.
>
> SCons and Waf arose as dynamic language realizations of ADG-based
> systems to replace Make and Autotools respectively.  They have a clear
> reason for existence and are successful, indeed have traction.  CMake
> likewise.
>
> Note here though there is a yawning gap between build frameworks in the
> JVM-verse and the native-verse.  Tools from one are generally rubbish in
> the other, to the detriment of build.
>
> If there is to be a new build framework to compete against SCons, Waf,
> CMake, Gradle and Maven I suggest it must be designed from the outset to
> deal with the vastly different problems of C, C++, D, LaTeX, Python,
> Ruby, Java, Groovy, Scala, Clojure, Erlang, Haskell, Chapel, Fortress,
> X10, etc.

I don't want a tool to compete against SCons, Waf and others. I want a 
simple tool for building D software. I think this is one of the problems 
with the other build tools, that they should be able to handle almost 
every language out there.

-- 
/Jacob Carlborg