This makes the disk usage footprint of building the kernel smaller in 3
ways:
1) There is no separate kernel source derivation
2) Rather than using the entire build tree, only the output of make
modules_prepare is kept in the $dev output (plus the module symbol
versioning file generated during the build)
3) Only the subset of the source tree known to be needed for external
builds is kept in $dev
Note that while 2) is supported by official kernel documentation, I
couldn't find any source describing what we need to keep for 3). I've
started with the bare minimum (the main Makefile is called by the
Makefile generated by make modules_prepare) and we can/should add more
as needed for kernelPackages.
Signed-off-by: Shea Levy <shea@shealevy.com>
This has three major benefits:
1. We no longer have two kernel build processes to maintain
2. The build process is (IMO) cleaner and cleaves more closely to
upstream. In partuclar, we use make install to install the kernel and
development source/build trees, eliminating the guesswork about which
files to copy.
3. The derivation has multiple outputs: the kernel and modules are in
the default `out' output, while the build and source trees are in a
`dev' output. This makes it possible for the full source and build tree
to be kept (which is expected by out-of-tree modules) without bloating
the closure of the system derivation.
In addition, if a solution for how to handle queries in the presence of
imports from derivations ever makes it into nix, a framework for
querying the full configuration of the kernel in nix expressions is
already in place.
Signed-off-by: Shea Levy <shea@shealevy.com>
- Unify the "single" and "float" variants, which are the same thing.
- Enable threads and openmp wrapper by default (they are very small).
- Don't use sse on i686, as I'm quite sure we have no warrant for that.
Cf. http://en.wikipedia.org/wiki/Pentium_Pro
- Disable static libs (big, no indication we need them).
- I tested most builds using fftw (they build OK).
In the most general case, the cross and native kernel may differ in
patches and configuration file as well as architecture, kernel target,
etc. It's probably overkill to support that case, but since it was
doable without much duplication and it will make integrating with the
existing cross-compilation support in the generic kernel I decided to
implement it anyway.
Signed-off-by: Shea Levy <shea@shealevy.com>
nix's version parsing treats the previous name as a package named
`linux' with version `${version}-source', when we really want a package
named `linux-source' with version `${version}'
Signed-off-by: Shea Levy <shea@shealevy.com>
