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

Nicolas Pierron nicolas.b.pierron at gmail.com
Thu Nov 19 19:09:49 CET 2009


Hi,

On Thu, Nov 19, 2009 at 18:29, Eelco Dolstra <e.dolstra at tudelft.nl> wrote:
> Hi,
>
> Nicolas Pierron wrote:
>
>> Author: NicolasPierron
>> Date: 2009-11-19 17:19:39 +0000 (Thu, 19 Nov 2009)
>> New Revision: 18468
>>
>> You can view the changes in this commit at:
>>    https://svn.nixos.org/viewvc/nix?rev=18468&view=rev
>>
>> Added:
>>    nixpkgs/branches/stdenv-updates/pkgs/lib/systems.nix
>> Modified:
>>    nixpkgs/branches/stdenv-updates/pkgs/lib/attrsets.nix
>>    nixpkgs/branches/stdenv-updates/pkgs/lib/default.nix
>>    nixpkgs/branches/stdenv-updates/pkgs/lib/types.nix
>>
>> Log:
>> Add systems.nix give more control over the increasing list of supported
>> systems.  This is not yet used because it has to be integrated with the
>> current system.
>
> Can you elaborate on this some more?  And how does it relate to the regular
> "system" value?

The system is represented by an attribute set which contains the cpu
type, the architecture (pc, apple, ...) and the kernel.  These fields
are attribute sets containing various informations like the bigEndian
/ littleEndian field for the cpu as well as the bus size.  The
architecture does not contains much information yet.  The kernel
contains the type of the executable format like ELF, PE, ... .

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;
}

except that this attribute set contains more information than what is
revealed by the simple string.  This means that you can express much
more with such attribute set than you would have been able with
strings.  Indeed, cygwin implies that the executable format is PE,
i686 implies that you are working with a little endian notation.

Such information can give you more control on program portability
without testing all the possible strings corresponding to your
particular case.

{stdenv, ...}:

# The program can only be build on a system which support the ELF format.
assert stdenv.lib.matchAttrs { kernel.execFormat.name = "elf"; }
stdenv.buildSystem;
# The program only support the litlle endian notation.
assert stdenv.lib.matchAttrs { cpu.signifiantByte.name =
"littleEndian"; } stdenv.hostSystem;

stdenv.mkDerivation {
  ...
};


Common patterns can be simplified by adding functions like:

isDarwin = matchAttrs { kernel = kernels.darwin; };
is64Bits = matchAttrs { cpu.bits = 64; };


You can still access you system name, by asking the name of each
attribute inside the system attribute set.

assert stdenv.buildSystem.name == "i686-cygwin";

Unless you use the mkSystemFromString (which define a custom name),
the default name of the system expression is:

"${cpu.name}-${arch.name}-${kernel.name}"


For sure, this file does not contains everything but we can imagine
adding cpu information for optimization purpose.


-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
If you are doing something twice then you should try to do it once.



More information about the nix-dev mailing list