Hi Andres, > If there actually is a build process involved, you have to select the > compiler for which you want to build the library. If multiple > versions of a compiler are around, and you still want to install via > nix-env, you have to multiply all libraries for all compiler > versions.
you are right, these kind of "variant builds" are a very tricky problem. If we'd come up with a powerful, generic solution to that, it would be quite an achievement. I believe, however, that wrappers like the one used in the new Python expression are not it, because this approach is not flexible enough. The problem of building variants applies not just to Python libraries or Haskell libraries, it applies to all package that have some sort of exchangeable dependency. For example, consider an application that supports various regular expression libraries, say both libpcre and libtre. In Nix, that application can easily be built with either library, but how do you generalize the case of building *both*? Similarly, a great many programs can be linked with glibc or dietlibc or any other implementation of libc. In Nix, we can easily switch C libraries by changing stdenv, but we cannot easily build all possible permutations, i.e. we cannot easily build everything with every available libc. Maybe I'm just missing an obvious insight, but I don't understand how the wrapper code found in the new Python expression improves that situation, even if it's just for Python. Let's say I want to build "cheetahTemplate" with both Python 2.5 and Python 2.6. How is that supposed to be done? My impression is that the recently added "override" feature is the way to go in that area. Just my 2 cents, Peter _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
