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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part