[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:58, Nicolas Pierron
<nicolas.b.pierron at gmail.com> wrote:
> 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)

In fact I am not doing the test ... The Nix test suite already takes
more than one hour to run on my computer^. (could be an infinite loop)

>>>> 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?
>



-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
Andrew S. Tanenbaum - Never underestimate the bandwith of a wagon full of tapes.