[Nix-dev] Re: Some missing build-env features

[Yury G. Kudryashov]

Michael Raskin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/08/2010 06:10 PM, Yury G. Kudryashov wrote:
>> The current buildEnv implementation lacks some useful features. I'd like
>> to rewrite it but I need some input before I'll start rewriting.
>>
>> The features I miss in buildEnv.
>> 
>> 1) Currently a runtime dependency must be a build time dependency as
>> well. This is bad because there are cycles.
> 
> I hope you didn't mean package runtime dependencies. But installation to
> profile could make buildEnv build and include some more packages.
Yes, I was talking about propagatedUserEnvPackages.
> 
>> 2) A package should be able to tell buildEnv to execute some commands
>> after symlinking dirs&files. Example: update-mime-info etc.
>> 
>> 3) A package should be able to tell buildEnv to skip some directories.
>> Various examples are currently hardcoded into build-env script.
>>
>> 4) A package should be able to tell buildEnv about required environment
>> variables. Examples: KDEDIRS, XDG_*, *_PLUGIN_PATH etc.
> 
> And what? You mean that buildEnv should build a file like setvars.sh
> that can be safely sourced by range of shells from Bourne sh to csh?
> 
> In what way should package tell this? It could ask to set a variable to
> something (conflict-prone), it could ask to run some hook to modify the
> variable (and then how we decide on the order?). Should such a hook have
> access to complete environment member list? Before or after propagation?
The easiest solution:

meta.requiredEnvVars = {
  QT_PLUGIN_PATH = {
    before = ""; # default
    after = ""; # default
    delimiter = ":"; #default
    paths = [ "/lib/qt4/plugins" "/lib/kde4/plugins" ];
  };
};

This should generate $profile/etc/env.d/90-qt-plugin-path.sh

unset QT_PLUGIN_PATH
for i in ${NIX_PROFILES}; do
  QT_PLUGIN_PATH=$i/lib/qt4/plugins:$i/lib/kde4/plugins${QT_PLUGIN_PATH:
+:}${QT_PLUGIN_PATH}
end
QT_PLUGIN_PATH="${before}${QT_PLUGIN_PATH}${after}"

"paths" should be merged, other conflicts should abort the build.
> 
>> What other features do you miss in the current buildEnv? I'm going to
>> propose a syntax for all above after we'll decide on required features.
> 
> Well, it would be nice to less Perl hacks and more Nix configurability.
> The notion of Nix profile doesn't seem nice to me, but I do have a few
> nix-expressions periodically built via nix-build and used in a way
> similar to profile. Having a nice buildenv that can be used inside such
> construction with unneeded features switched off could be nice.
I'm talking about nixpkgs/pkgs/build-support/buildenv (used in NixOS), not 
about nix buildEnv (used in nix-env).