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
