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>
This only affects the `oldaskconfig' make target, so it shouldn't really
affect current manual-config users, but it does make it more
straightforward to implement the generic kernel build on top of
manual-config.
Signed-off-by: Shea Levy <shea@shealevy.com>
If the config attrset is manually specified, we still want isYes,
isModule, etc. to work. But we let the passed in config attrset take
precedence, if for some reason the caller wants to provide their own
implementation of one or more of these functions.
Signed-off-by: Shea Levy <shea@shealevy.com>
With this, I was able to successfully compile a defconfig kernel for the
sheevaplug, though I didn't actually try to run it (not having a
sheevaplug myself).
For native compiles, the most significant difference is that the
platform's kernel target is built directly rather than hoping the
default make target will pull it in.
Also some stylistic improvements along the way.
Signed-off-by: Shea Levy <shea@shealevy.com>
In addition to replacing use of a feature with IMO confusing semantics,
this will also let us cleanly separate out all-packages.nix into
category-specific files without changing the structure of the pkgs
attrset.
Signed-off-by: Shea Levy <shea@shealevy.com>
fixes#1355. partial revert of f4d4e12c (introduced by #1313).
meta.priority is set to 6 (lower priority than standard) to resolve the
conflict of an exported gschemas.compiled for evince as for nm-applet.
this linked file is NOT consulted, as both binaries are wrapped to look
for their schemas in their nix store path first.
a better fix would avoid already avoid linking those gschemas.compiled
files into the environment.
Matplotlib is currently using hacked together build / install phases
which mimick this functionality of buildPythonPackage. This patch
changes the expression to remove the duplicated build scripting.
This patch also bumps up the HPN version of openssh so that it compiles
on top of 6.4. Along with the bump, a package was added for the high
performance networking version.
The gcmrekey patch was removed as this vulnerability is fixed in
version 6.4 onward. http://www.openssh.org/txt/gcmrekey.adv
Instead of applying all of the patches, this build pulls an archive from
the source code repo with all of the patches already applied. This is the
preferred way from http://www.vim.org/sources.php
Currently, btrfsprogs is misdetected by nix such that it requires
specifying btrfs-progs-v3.12 for install instead of just btrfs-progs.
This patch removes the v so that it now reads btrfs-progs-3.12 and is
properly detected by nix.
attribute in the compiler-specific package set
binary has become a core package in ghc 7.4.2, so we cannot easily build
stuff with our own version of it. (Least not without Cabal warning about
version conflicts in the build log.)
disabled by setting 'strictConfigurePhase' to 'false'
This is necessary for some packages, like dns, because cabal warns about
multiple versions of the same dependency being used, but the usage is fine,
actually, so we want the build to succeed. Packages that depend on 'doctest'
also have this issue <https://github.com/sol/doctest-haskell/issues/69>.
