On 2013-02-16 21:02, Johannes Pfau wrote:
Having a common standard build tool is always good. But some kind of projects require custom build scripts (calling swig, generating interface files for ipc stuff, executing the C compiler to check if a function is available to disable / enable additional features, calling pkgconfig for some reason, compiling additional c/c++ files, assembling additional files, ...).I think splitting DUB into a package manger and build tool would be a good idea. Ship them as one package, so that everyone using the package manager also has the build tool installed. And integrate them as much as possible, the default setup can still work exactly the same as if they were integrated. The benefit of splitting them in this way: You're forced to provide interfaces for the build tool to communicate with the package manager and every other build tool can use those interfaces as well. This way there are no second class build systems. As an example: package.json { "name": "myproject", "description": "A little web service of mine.", "authors": ["Peter Parker"], "homepage": "http://myproject.com";, "license": "GPL v2", "dependencies": { "vibe-d": ">=0.7.11" }, "build": "DUB" } build.json { "configurations": { "metro-app": { "versions": ["MetroApp"], "libs": ["d3d11"] }, "desktop-app": { "versions": ["DesktopApp"], "libs": ["d3d9"] } } } doing a "dub-pkg install myproject" should fetch the sources, then call "dub-build build.json". dub-build will have to ask the package manager for some information: "dub-pkg package.json --query dependencies", "dub-pkg package.json --query --package=vibe.d --link-path". Or it might require some additional actions: "dup-pkg --install-dependency d3d9"
Exactly. But I see no reason for communicating with processes. Just make them both into libraries and call functions plain functions.
-- /Jacob Carlborg
