| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
file) is now generated from that using `w3m' and some XSL hackery.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reported by Rob Vermaas.
|
|
dependencyClosure { ... searchPath = [ ../foo ../bar ]; ... }
* Primop `dirOf' to return the directory part of a path (e.g., dirOf
/a/b/c == /a/b).
* Primop `relativise' (according to Webster that's a real word!) that
given paths A and B returns a string representing path B relative
path to A; e.g., relativise /a/b/c a/b/x/y => "../x/y".
|
|
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.
|
|
|
|
kind of ad hoc ;-)
|
|
|
|
so that we don't produce un-wellformed XML.
|
|
|
|
automatically.
|
|
|
|
[1 2 3] ++ [4 5 6] => [1 2 3 4 5 6]
|
|
|
|
working when PATH is unset.
|
|
|
|
|
|
|
|
(closed(closed(closed(...)))) since this reduces performance by
producing bigger terms and killing caching (which incidentally also
prevents useful infinite recursion detection).
|
|
|
|
|
|
* Add lexical restrictions for keywords.
|
|
|
|
|
|
So when using Nix as a build tool, you can just say `nix-build' and
it will build the top-level derivation defined in `default.nix'.
|
|
|
|
with default values automatically. I.e., e -> e {}.
This feature makes convenience expressions such as
pkgs/system/i686-linux.nix in Nixpkgs obsolete, since we can just do
$ nix-instantiate ./pkgs/system/all-packages.nix
since all-packages.nix takes a single argument (system) that has a
default value (__thisSystem).
|
|
handle it. It crashed on the 234 MB tetex archive. Probably we
will never be able to handle archives of that size on 32-bit
machines (because bsdiff does everything in memory requiring
max(17*n,9*n+m)+O(1) bytes, so the address space simply isn't
there).
|
|
`removeAttrs attrs ["x", "y"]' returns the set `attrs' with the
attributes named `x' and `y' removed. It is not an error for the
named attributes to be missing from the input set.
|
|
|
|
|
|
|
|
unpacking and repacking of intermediate paths.
|
|
|
|
|
|
|
|
|
|
they cause Nix builds to have unnecessary retained dependences
(e.g., on Subversion).
|
|
makes most query and installation operations much faster (e.g.,
`nix-env -qa' on the current Nixpkgs is about 10 times faster).
|
|
|
|
* Make the `derivation' primitive much more lazy. The expression
`derivation attrs' now evaluates to (essentially)
attrs // {
type = "derivation";
outPath = derivation! attrs;
drvPath = derivation! attrs;
}
where `derivation!' is a primop that does the actual derivation
instantiation (i.e., it does what `derivation' used to do). The
advantage is that it allows commands such as `nix-env -qa' and
`nix-env -i' to be much faster since they no longer need to
instantiate all derivations, just the `name' attribute. (However,
`nix-env' doesn't yet take advantage of this since it still always
evaluates the `outPath' and `drvPath' attributes).
Also, this allows derivations to cyclically reference each other,
for example,
webServer = derivation {
...
hostName = "svn.cs.uu.nl";
services = [svnService];
};
svnService = derivation {
...
hostName = webServer.hostName;
};
Previously, this would yield a black hole (infinite recursion).
|
