[Nix-dev] How a nix gui tool might look like? - what about derivation = { alsoInstall =

Marc Weber marco-oweber at gmx.de
Mon May 12 01:51:23 CEST 2008


Sanders mail has reminded of one issue I'll get some trouble with:
There is a list of use cases for one pattern:

application > libs or plugins
eclipse > plugins
C/C++ > header and libs
ghc > libs
python > libs
perl > libs

Maybe ghc is propably most limited in libraries which can be used,
because libs have to be compiled by the same ghc version
Thus if you install a ghc library this implies you want the compiler as
well.
I've implemented it this way

        createGHCWrapper = ghc : listOfLibs : [ ..]

this function creates a script adding all the libs to a env var GHC_PKG_PATH
I like this approach because there are very few files to be added to .nix-profile
but:
        special case needed to make a gui tool install the libraries.
        So my decision was bad.

I can think of two different solutions:
a) allow kind of post-install-scripts generating the wrappers based on
information found in .nix-profile
b) make the wrapper collect this information at runtime

Right now I think b) is the best one because it requires no change of
the env builder. I already had implemented a) some time ago..

Do you think it would be an enhancement adding another special attribute
to derivation expressing this lib -> compiler install dependency ?

example:
libCompiledByGHC = derivation {
        name = "libCompiledByGHC-0.0";
        buildInputs = [ ghc ];
        # ! new: !
        alsoInstall = [ ghc ];
}

Then the gui tool would know that installing
ghc-6.8.2-libCompiledByGHC-0.0 implies installing ghc-6.8.2 ?

The same could be used for lib dependencies.
Example:
A depneds on B, A and B are libs compiled by ghc.
ghc now recquires installing B as well if you need A.

A = {
        [...]
        alsoInstall = [B];
}

Any comments?

Marc Weber



More information about the nix-dev mailing list