[Nix-dev] Re: Which is the best way to pass dependencies?

Andres Loeh andres.loeh at googlemail.com
Tue May 20 18:24:53 CEST 2008


Hi.

> (A) Using kind of register script (I think this is like the longer existing ghc implemetnation does it?)

Yes, almost.

>     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

It's only a difference in terminology.
The libraries don't actually use a setupHook, only a shell script in a
predefined
location in nix-support.

I don't quite get what localpkgdb.installto is for. This is an
implementation detail
of the script the package is executing to register its package. The
current expression
has Cabal generate the scripts and then patches them slightly. This is not very
nice.

> (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

I think that's quite ok. Again, instead of creating
localpkgdb.installto we should just use
"Setup register --gen-pkg-config" to generate (a) suitable file(s).
Also, there's no real
need to collect the paths in an environment variable. If every library
puts its databases into
nix-support/ghc-pkg-dbs, nix_ghc_tool can pick them up from there.

>     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)

I don't quite get this. envHooks are called on all propagatedBuildInputs anyway,
so it seems easier to add all of them. So I'm in favour of (a variant of) B1.

Cheers,
  Andres



More information about the nix-dev mailing list