Hello,
and thanks a lot for your reply, I will closely look about stdenvType in
stdenv/default.nix and send some feedback.
Perhaps a more elegant solution in my case should be to define "fake"
nix packages for native tools that just encapsulate them instead of
adding /usr/bin to $PATH "just" to provide gcc for instance (and
"benefit" of all the tools in /usr/bin/ ..).
It could be something as dirty as creating symlinks to system files and
folders in the build process of such as package (from the output of
native package listing like "rpm -ql <package>" for instance).
It should be closer to the purity way to do of nix packages.
This way to do should provides a more fine grain control on what is used
during a build process of packages and should allow to "easily" switch
between gcc-native and a gcc provided by a nix package.
Regards,
Pierre Bourgin
Yurii Kudryashov a écrit :
On Nov 16, 2007 9:48 AM, Pierre Bourgin <[EMAIL PROTECTED]> wrote:
Hello,
Contrary the nix purity philosophy, I would like to use a lot of
tools/libs provided by my Linux distribution, instead of relying only on
nix packages (and thus rebuild a complete system in the nix world).
I would like also to keep the ability to easily switch from a platform
tool onto a nix packaged one.
Example:
. use libc from the platform (always)
. use gcc from the platform (/usr/bin/gcc)
. use a newer gcc than /usr/bin/gcc : use a nix package
I've began to read file pkgs/top-level/all-packages.nix and files
related to stdenv, but I can't figure out how to reach this goal.
It seems that you are looking for stdenvNative. For example you can
apply the following:
- if stdenvType = "i686-linux" then stdenvLinux
+ if stdenvType = "i686-linux" then stdenvNative
to stdenv/default.nix. It seems that after this patch system tools
will be used for building other packages. I haven't tried it but I
hope that it should work.
In my mind, the most lazy way to do this will be to create
my-packages.nix with a code like:
import ./pkgs/top-level/all-packages.nix
then modify some attributes (or redefine them), in order to use the libc
or gcc from the platform for instance.
It is not enough because in this case your "native" tools will not be
used for building other packages.
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
