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

[Nicolas Pierron]

Hi,

On Fri, Nov 20, 2009 at 11:30, Ludovic Courtès <ludo at gnu.org> wrote:
> Nicolas Pierron <nicolas.b.pierron at gmail.com> writes:
>> On Thu, Nov 19, 2009 at 23:29, Ludovic Courtès <ludo at gnu.org> wrote:
>>> Nicolas Pierron <nicolas.b.pierron at gmail.com> writes:
>>>> The architecture does not contains much information yet.  The kernel
>>>> contains the type of the executable format like ELF, PE, ... .
>>>
>>> It’s the dynamic linker that deals with executable file formats.
>>
>> Except if you are downloading a pre-compiled version.
>
> It’s the dynamic linker that actually parses the ELF file, etc., not the
> kernel.  See ld.so(1) on a GNU system, for instance.

But the dynamic linker does not downloaded pre-compiled versions of
any software.  So you need to know what executable format / kernel is
used for the host derivation in order to choose wisely.

>>>> Such details give you more control compared to the usual strings.  As
>>>> example "i686-cygwin", is converted to the following set: (with the
>>>> function mkSystemFromString)
>>>>
>>>> { cpu = cpuTypes.i686;
>>>>   arch = architectures.pc;
>>>>   kernel = kernels.cygwin;
>>>> }
>>>
>>> How is the ‘arch’ bit inferred from “i686-cygwin”?
>>
>> Unfortunately it is not.  This is just a guess because (in general)
>> the string is not expressive enough to infer such thing.
>
> So what’s the point?

The architecture is currently unused, but Luis reported that he need
such thing for his arm's compilation because "sheevaplug" architecture
is not the same as the one emulated by "qemu".  So, if this currently
has no meaning for pc / macs, this may have some for others.

>>> Overall, I feel that it’s nice to have more than just strings like
>>> “i686-cygwin”, but I’m also slightly afraid of overdesign: building an
>>> exceedingly complex model that’s too hard to keep close to reality.
>>
>> Could you develop what you are afraid of?
>
> As can be seen from the examples above, the attribute set you’re
> proposing is very detailed, but its actual meaning is ill-defined.

That's why I haven't used it yet.  May be you can help us at defining
clearly the important points and at rearranging it accordingly to
hardware definition.

> In addition, in a pure NixOS setup, all programs need to know are the
> architecture and the kernel (as in “i686-linux”), because these are the
> only elements not part of the dependency graph.  Every missing piece of
> information is inferred from there: glibc provides <endian.h>, cpp
> defines macros such as ‘__x86_64’, etc.

Such macros are provided for developers.  So if a developer want to
port his application to an x86_64 machine, then he can use them.
Unfortunately, checking if the program is using such headers does not
guarantee you that the program is portable.  You cannot statically
determine if a program can safely be ported to any other host.

The system attribute set give you such control and allow you abort
before the beginning of the compilation.  In addition, no program are
well written, and all may not rely on "i686-cygwin" during their
configuration stage because they don't have one.  So you need such
information to tweak Makefiles (as sometimes specified in the README).

> Now, hardware in general is not part of the dependency graph, and some
> programs need more info about the hardware than just the CPU type, and
> info that’s not provided through a kernel interface such as uname(2).
> The only type of programs that fall into this category are boot loaders,
> AFAICT (actually GRUB 2 seems to be happy with whatever ‘config.guess’
> tells it, so we’re really talking about U-Boot.)
>
> This would mean that the main (only?) purpose of this API you’re
> designing is to build U-Boot.  That’s what I call “overdesign”.

I've created this library because the string representation was not
enough.  I don't claim that all of its part are required, but it just
contains a set of ideas to show how you can create such system
expression.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
Richard Feynman - I think I can safely say that nobody understands
quantum mechanics.