[Nix-dev] Re: [Nix-commits] SVN commit: nix - 18468 - NicolasPierron - nixpkgs/branches/stdenv-updates/pkgs/lib

[Nicolas Pierron]

On Fri, Nov 20, 2009 at 19:19, Ludovic Courtès <ludo at gnu.org> wrote:
> Hi,
>
> Lluís Batlle <viriketo at gmail.com> writes:
>
>> The kind of information it needs for cross-compilation may be
>> *different*, once some of the build system information can be
>> automatically asked to the OS or the hardware, but that of the cross
>> compilation no.
>
> Right.
>
>> If nix offered a full abstraction of the system where things build or
>> things are built for, we would achieve that the information for both
>> native and cross builds will be enough and the same.
>
> For pure native builds, I’m pretty sure ‘currentSystem’ and the
> dependency graph are all one needs.
>
> For cross builds, this information may indeed be insufficient, because
> one can’t actually run code to determine, say, the available CPU or
> kernel features.
>
> This would justify an additional ‘host’ argument for expressions that
> are to be cross-compiled, possibly with more info than just CPU-kernel.
>
> But then, I find it troublesome if all of Nixpkgs has to pay the price
> of this additional complexity, especially now that you showed it’s
> possible to natively compile NixOS on the SheevaPlug.

What price?

- evaluating dozen of attribute sets?
- matching subsets of information?

Or may be you prefer:

- Duplicating expressions for special hardware support?
- Comparing among an undefined set of strings?

I am ready to pay this *extremely small* price in order to have
support for undetected hardware and for future optimizations.  If you
think, that is an hard work to be computed for each derivation, I
recall you that Nix use maximal laziness.  To be clear on this point,
without maximal laziness you won't be able to evaluate NixOS in a few
seconds. (doing the test on his computer)

>>> glibc, mplayer, etc. all detect this at run time.  (In glibc 2.10, ELF
>>> was even extended with ‘STT_IFUNC’ so that code for all ISA variants can
>>> be compiled in and the right version is chosen by the dynamic linker.)
>> Not all programs may detect that at runtime, and choose that at build
>> time. It maybe that it is the case of atlas.
>
> Yes, but then it’s buggy: you wouldn’t be able to rely on an Atlas
> binary compiled on the build farm, for instance.  In Nix parlance, this
> is actually an impurity.  (GMP’s extended ‘config.guess’ can yield to
> similar issues, which is why we override it with the standard
> ‘config.guess’ [0].)

Which clearly means that all dependencies are not derivations, but
also the host properties.


-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
The Hitchhiker's Guide to the Galaxy - What do you get if you multiply
six by nine?