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

[Jacob Carlborg]

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