nix-super/make/lib/find-includes.pl

use strict;

my $root = $ENV{"main"};
my $out = $ENV{"out"};

open OUT, ">$out" or die "$!";
print OUT "[\n";

open IN, "<$root" or die "$!";
while (<IN>) {
    if (/^\#include\s+\"(.*)\"/) {
        print OUT "\"$1\"\n";
    }
    if (/^\#include\s+\<(.*)\>/) {
        print OUT "\"$1\"\n";
    }
}
close IN;

print OUT "]\n";
close OUT;
* 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 15:38:47 +03:00			`use strict;`

			`my $root = $ENV{"main"};`
			`my $out = $ENV{"out"};`

			`open OUT, ">$out" or die "$!";`
			`print OUT "[\n";`

			`open IN, "<$root" or die "$!";`
			`while (<IN>) {`
			`if (/^\#include\s+\"(.*)\"/) {`
* `dependencyClosure' now allows a search path, e.g., 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". 2005-08-14 17:00:39 +03:00			`print OUT "\"$1\"\n";`
			`}`
			`if (/^\#include\s+\<(.*)\>/) {`
* 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 15:38:47 +03:00			`print OUT "\"$1\"\n";`
			`}`
			`}`
			`close IN;`

			`print OUT "]\n";`
			`close OUT;`