On 05/21/2016 03:53 PM, Bjørn Forsman wrote: > In Nix: > I'm actually unsure about the details here, but I *think* the standard > builder simply takes the first output of each package in buildInputs. [...]
Yes, the first but that one typically propagates other outputs - by default the ones including headers, libraries and binaries. You can choose which by setting propagatedBuildOutputs = [ "foo" "bar" "out" ]; > [...] > First I tried to figure out a way to union Nix outputs into one "all" > output. The idea is that we need more finely split packages, but that > isn't really feasible unless we can easily bundle them together first, > for builds. But I couldn't come up with anything that wouldn't end up > referencing the "all" output, which would prevent garbage collection. BTW, there is also myPackage.all - a list of all output paths. > [...] > $ nix-build -A pkgconfig > /nix/store/wndacaca5dq5cpyfa41v1fv4sfhr0y77-pkg-config-0.29 > $ nix-build -A pkgconfig.share > /nix/store/wndacaca5dq5cpyfa41v1fv4sfhr0y77-pkg-config-0.29/share > $ nix-build -A pkgconfig.share.doc > /nix/store/wndacaca5dq5cpyfa41v1fv4sfhr0y77-pkg-config-0.29/share/doc > > (Note that all outputs have the same store path prefix.) > [...] That is similar to what regular distros use... only they drop the hashed prefixes completely. The problem is with detecting runtime dependencies. First, we only scan for the hash part AFAIK. We might change that to scan for the whole prefix, but if someone gets a reference to pkgconfig.share.doc, one can do ../../lib/foo and get to other outputs (!) Sure it would actually solve some problems due to packages assuming everything is in the same output, but we would sacrifice part of purity, e.g. GC could break reachable stuff. --Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
