Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/19 Jacob Carlborg <doob at me.com>:
>> Apperently some projects need to have their buildsystem check for the
>> existance of, locations of, and details about certain things on the local
>> system before building. So...that stuff.
>
> Isn't that to check what libraries, and so on, are present? That is the
> whole point of a package manager. A package specifies what dependencies it
> has, then the package manager makes sure the dependencies are met, or else
> it can't be installed.

All "dependencies" aren't always mandatory. It's not uncommon for some
software to adapt itself to the environment, say enabling certain
features IF certain other packages can be found, otherwise just
disable the functionality. Also it might adapt itself on other
conditions, say auto-detecting checking what OS-kernel we are building
for, and pass along D versions-keywords accordingly, including
allowing the user to override, to do cross-platform or cross-version
builds. Also, most build-systems offers options for whomever is
building, such as --use-test-codeX, much like Tango now allows you to
build with the regular, or the less tested concurrent GC.

> Don't know what locations it would check for. The package as no saying in
> where it should be installed, the package manger decides that.
Same here. You may have multiple builds of the same package, and want
to cross test a dependent package against two different installs to do
regression-testing. (Or the classic i386/x86_64 debacle)

> Oh, now I mixing package manager and build tool and assume the build tool
> will be used with the package manager.
I think the build-tool and package manager must be independent, but
well integrated. Otherwise, you risk making it difficult for
D-software to come by default in Linux-distros, and you make it
difficult for the D-package-manager to carry a package with a
different build-system (even a D based package with different
build-system).