On 2011-04-01 20:44, Bruno Medeiros wrote:
> On 19/03/2011 14:36, Jacob Carlborg wrote:
>> On 2011-03-18 18:04, Chris Manning wrote:
>>> On 17/03/2011 22:49, Jason E. Aten wrote:
>>>> Somewhat tongue in cheek, we could call it dabal.
>>>>
>>>> As in, "get on dabal!" :-)
>>>
>>> If D gets accepted for Google Summer of Code, I think this would be a
>>> great idea for a project and I would be interested in implementing it as
>>> a student. Although, it does seem overly ambitious so maybe only some of
>>> this could be for the gsoc (and if I do this It'd be great to carry on
>>> working on it anyway).
>>>
>>> What does everybody think about this? Should I draw up a proposal of
>>> some kind?
>>>
>>> Chris
>>
>> I've been thinking for quite some time to build a package management
>> system for D, lets call it dpac as an example. This is the ideas that I
>> have:
>>
>> Basically copy how RubyGems works.
>> Use Ruby as a DSL for dpacsepc files which is used to create to create
>> the dpac file. This is an example for how a file used to build a package
>> could look like:
>>
>> name "Foo Bar"
>> summary "This is the Foo Bar package"
>> version "1.0.0"
>> type :lib
>> author "Jacob Carlborg"
>> files ["lib.d"] # list of the files in the package
>> build :make # other options could be :dsss :cmake and so on
>> dversion 2 # D1 or D2
>>
>
> Copying Rubygems would be a bad idea, or at least a very incomplete one.
> And the example code above shows why, doesn't anyone else see it?
> Just look at the line:
> build :make # other options could be :dsss :cmake and so on
> Basicly, this would be a D package manager that requires another package
> manager to build D artifacts... kinda not very useful, right? If we skip
> the issue of building D artifacts (executables, dynamic libraries,
> static libraries, etc.) we skip one essential aspect of a D
> package/build management system (if not the main aspect, but that is
> debatable...). This is why I think just copying/cloning a PM from
> interpreted languages is not helping us much.

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.

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.

-- 
/Jacob Carlborg

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@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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