Hi Alex, On 2 December 2013 09:43, Alex Berg <[email protected]> wrote: > I am interested in this topic. I don't completely understand the problem > here, but maybe I can help by discussing it. > > The motivation for the addition of "runtimeInputs" is primarily to support > language interpreters and their libraries?
Yes. For C/C++ buildInputs tend to "stick" into the binaries/libraries through RPATH. So they have automatic/implicit runtime deps handling. But there is no similary "stickyness" for e.g. shell scripts and python programs. That's why we currently use wrapProgram and such to make the dependencies "stick around" after the build environment is destroyed. > First, I would like to better understand the concept. How do you want to use > these "runtimeInputs"? You want to add them to an environment variable, such > as "PATH", and keep this value after the build environment closes? Or you > want to modify the interpreter's package by adding symlinks to this > "buildInputs" packages? The latter. Say that the derivation for progA has runtimeInputs = [ bash dep1 dep2 ]. Nix should build a symlink tree with bash, dep1 and dep2. Then modify bash so that it gets PATH=symlink-tree/bin (either with a wrapper or sourcing some setup code). In the fixupPhase we could patch the shebangs in $out/ to use the bash interpreter that has the pre-set PATH to all runtime deps of progA. And the same should be doable for python/perl/ruby.... > Currently, "buildInputs" packages are built before the package, and their > "bin", "lib", and "include" directories are added to certain environment > variables so other tools can find them, but only during the build. Am I > wrong, or does it do other important things? (If there's documentation that > fully explains the effects of adding a package to this attribute, please > link me.) Your idea of buildInputs is the same as mine. > Also, I remember that "propagatedBuildInputs" also exists. I don't > understand its exact purpose, but I believe it shares environment variables > between dependencies, from child to parent packages. Is "runtimeInputs" > similar? runtimeInputs is different from propagatedBuildInputs. Maybe there could be a propagatedRuntimeInputs though. I think the nixpkgs manual describes propagatedBuildInputs best: """ Like buildInputs, but these dependencies are propagated: that is, the dependencies listed here are added to the buildInputs of any package that uses this package as a dependency. So if package Y has propagatedBuildInputs = [X], and package Z hasbuildInputs = [Y], then package X will appear in Z’s build environment automatically. """ Best regards, Bjørn Forsman _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
