passing deps:
dep graph ( C depends on B,D depending on A), thus A is found twice when
traversing deps of C !
A - > B -> C
`-> D -> `
example what happens when building C:
(A) Using kind of register script (I think this is like the longer existing ghc
implemetnation does it?)
A1 using propagatedBuildIpnuts:
# create local package db
echo [] > localpkgdb.deps
runSetupHooksOfDeps # all deps are registering themselves
echo [] > localpkgdb.installto
# build packages
# expose this lib
createSetupHook localpkgdb.installto # creates script
registering package
(B) using env var to pass deps
B1 using propagatedBuildIpnuts
# create local package db
runSetupHooksOfDeps # all deps are only adding their local dbs
to GHC_PACKAGE_DB
nix_ghc_tool --local-db-from-env localpkgdb.deps # reads
GHC_PACKAGE_DB and joins all those listed files
echo [] > localpkgdb.installto
# build packages
# expose this lib
createSetupHook localpkgdb.installto # create script adding
localdb to GHC_PACKAGE_DB
B2 using buildinputs only
# create local package db
runSetupHooksOfDeps # all deps are only adding their local dbs
to GHC_PACKAGE_DB
nix_ghc_tool --local-db-from-env localpkgdb.installto # reads
GHC_PACKAGE_DB and joins all those listed files
>>> ^^^^ we will install
>>> to this db thereby exposing the deps as well
# build packages
# expose this lib
createSetupHook localpkgdb.installto # create script adding
localdb to GHC_PACKAGE_DB
Here B2 makes some difference compared to B1 and A:
B2 is the only one exposing the build lib and its dependencies. This will be
more efficient if we get really big graphs somewhen in the future
I think B will be more efficient than A on cygwin because forking is expensive
(ghc-pkg is used to register packages)
Marc
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
