The DUB package manager

Johannes Pfau nospam at example.com
Sat Feb 16 12:02:25 PST 2013


Am Sat, 16 Feb 2013 11:37:00 -0800
schrieb "H. S. Teoh" <hsteoh at quickfur.ath.cx>:

> 
> Having a standardized way of generating build scripts is good, because
> then the D package manager can target the *end user*'s preferred build
> system, rather than whatever build system the package writers chose.
> The package writers can just specify how to build the stuff, then let
> the D packager generate makefiles for one user, Ant files for another
> user, etc.. This makes it much more friendly to use, and therefore,
> more likely people will actually use it.
> 

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"


More information about the Digitalmars-d mailing list