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