The DUB package manager

[Jacob Carlborg]

On 2013-02-16 19:39, Sönke Ludwig wrote:

> Not at all, the idea is to have a number of "build script" generators so
> everyone can choose whatever fits best, otherwise a generic rdmd/dmd
> based build works out of the box with no need to install an additional
> tool. Invoking a generic external tool is easy enough to add and already
> planned, so this should not be a limiting factor in any way.

Ok, I see. But it feels wrong to me that it should generate a build 
script. I think the package should already contain a build script.

> What makes you think so? Just because of your definition of "package
> manager" or for a concrete reason? There are things like setting up
> import paths to dependent projects that only the package manager can do,
> because it knows their locations (and it can be desirable for many
> reasons to not install dependencies into a predefined place). Bringing
> package management and build receipt together is convenient and natural
> here.

I'm thinking that there should be a build tool that drives everything. 
The build script contains package dependencies. The build tool will ask 
the package manager to get linker/import paths and libraries for the 
dependencies.

But I guess that basically the same as how DUB is working. But the 
package manager drives everything instead of the build tool.

> You could also say that it is a meta-build tool (along the lines of
> cmake) with package support if you want.

> There should be no problem with that. The API will need to be cleaned up
> a bit, but generally it's a shallow "app.d" file that does command line
> processing and a number of modules that do the actual work (in a package
> "dub").

Good, that's how it's supposed to be organized.

-- 
/Jacob Carlborg