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

Russel Winder russel at russel.org.uk
Sat Apr 2 23:55:05 PDT 2011


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?

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.

-- 
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/20110403/2dc6eb99/attachment.pgp>


More information about the Digitalmars-d mailing list