[Nix-dev] how to use platform tools (gcc, libc) with nix ?

[Pierre Bourgin]

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 <pierre.bourgin at arteris.com> 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.