2005-05-02 15:25:28 +00:00
|
|
|
rec {
|
|
|
|
|
|
|
|
# Should point at your Nixpkgs installation.
|
|
|
|
pkgPath = ./pkgs;
|
|
|
|
|
|
|
|
pkgs = import (pkgPath + /system/all-packages.nix) {};
|
|
|
|
|
|
|
|
stdenv = pkgs.stdenv;
|
|
|
|
|
|
|
|
|
2005-08-14 14:00:39 +00:00
|
|
|
compileC =
|
|
|
|
{ main
|
|
|
|
, localIncludes ? "auto"
|
|
|
|
, localIncludePath ? []
|
|
|
|
, cFlags ? ""
|
|
|
|
, sharedLib ? false
|
|
|
|
}:
|
2005-05-02 15:25:28 +00:00
|
|
|
stdenv.mkDerivation {
|
|
|
|
name = "compile-c";
|
|
|
|
builder = ./compile-c.sh;
|
2005-08-14 14:00:39 +00:00
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
localIncludes =
|
|
|
|
if localIncludes == "auto" then
|
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 12:38:47 +00:00
|
|
|
dependencyClosure {
|
|
|
|
scanner = main:
|
|
|
|
import (findIncludes {
|
|
|
|
inherit main;
|
|
|
|
});
|
2005-08-14 14:00:39 +00:00
|
|
|
searchPath = localIncludePath;
|
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 12:38:47 +00:00
|
|
|
startSet = [main];
|
|
|
|
}
|
2005-05-02 15:25:28 +00:00
|
|
|
else
|
|
|
|
localIncludes;
|
2005-08-14 14:00:39 +00:00
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
inherit main;
|
2005-08-14 14:00:39 +00:00
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
cFlags = [
|
|
|
|
cFlags
|
2005-08-14 10:19:55 +00:00
|
|
|
(if sharedLib then ["-fpic"] else [])
|
2005-08-14 14:00:39 +00:00
|
|
|
(map (p: "-I" + (relativise (dirOf main) p)) localIncludePath)
|
2005-05-02 15:25:28 +00:00
|
|
|
];
|
|
|
|
};
|
|
|
|
|
2005-08-14 14:00:39 +00:00
|
|
|
|
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 12:38:47 +00:00
|
|
|
findIncludes = {main}: stdenv.mkDerivation {
|
2005-05-02 15:25:28 +00:00
|
|
|
name = "find-includes";
|
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 12:38:47 +00:00
|
|
|
realBuilder = pkgs.perl ~ "bin/perl";
|
|
|
|
args = [ ./find-includes.pl ];
|
|
|
|
inherit main;
|
2005-05-02 15:25:28 +00:00
|
|
|
};
|
2005-08-14 14:00:39 +00:00
|
|
|
|
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
link = {objects, programName ? "program", libraries ? []}: stdenv.mkDerivation {
|
|
|
|
name = "link";
|
|
|
|
builder = ./link.sh;
|
|
|
|
inherit objects programName libraries;
|
|
|
|
};
|
|
|
|
|
2005-08-14 14:00:39 +00:00
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
makeLibrary = {objects, libraryName ? [], sharedLib ? false}:
|
|
|
|
# assert sharedLib -> fold (obj: x: assert obj.sharedLib && x) false objects
|
|
|
|
stdenv.mkDerivation {
|
|
|
|
name = "library";
|
|
|
|
builder = ./make-library.sh;
|
|
|
|
inherit objects libraryName sharedLib;
|
|
|
|
};
|
|
|
|
|
2005-08-14 14:00:39 +00:00
|
|
|
|
2005-05-02 15:25:28 +00:00
|
|
|
}
|