The DUB package manager

[Sönke Ludwig]

Am 16.02.2013 19:10, schrieb Jacob Carlborg:
> 
> I think it looks like you're tying the user to a particular build tool.
> I don't think it's the business of the package manager to build
> software. That's the job of a build tool. The package manager should
> just invoke the build tool. You just need to support a few build tools,
> like rdmd, make and then also support shell script.

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.

> 
> Things like setting compiler flags does really not belong in a package
> manger.

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.

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

> 
> I have not looked at the source code for DUB at all. In general how is
> it organized. Can it be used as a library to easily build, say a GUI or
> directly integrate into an IDE?
> 

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").