2011/7/19 Jacob Carlborg <d...@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).