If I understand getPkgConfig correctly, then getPkgConfig A B default
will check the configuration file for a key A.B, and if that is not present, for a key B. As a final resort, if neither A.B nor B are set, default is returned. A common use case is to say if getPkgConfig "mypackage" "myfeature" false then ... else ... in order to conditionally enable something depending on a user-defined flag. If myfeature is shared between multiple packages, then a user can globally specify whether (s)he wants the feature by saying "myfeature = ..." in the config file. The problem arises once there is another line somewhere in Nixpkgs that says getPkgConfig "myfeature" "foo" false in other words, if "myfeature" happens to be the name of another package. This problem is real. One example where this problem currently arises is the following: In all-packages.nix, in the definition of distcc, we have python = if getPkgConfig "distcc" "python" true then python else null; There are several other lines of the form getConfig ["python" ...] That means, if someone sets for instance python.curses = true in the configuration file, then the getPkgConfig line above will result in a run-time type error. I think this problem needs to be addressed. I know that Eelco dislikes getPkgConfig/getConfig in general, and I tend to agree. However, I do not want to propose any far-reaching changes. A relatively easy fix would be to make getPkgConfig A B not check A.B and B, but A.B and global.B (or some other name instead of global). That would significantly reduce the chances of name clashes. Cheers, Andres _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
