The 3.4 code was tested preliminary in x-updates,
described by 2e4eab1228.
Updates to llvm break builds of dependent packages (in all cases I've seen),
and often upstream isn't too fast in porting to the newest version.
Consequently, it seems better to keep more versions (two ATM),
both in one file to share eventual changes.
Also, using versioned llvm_* attributes is proposed because of this.
All this accomplishes is to make bison depend on flex, which in turn
depends on bison. (So as a result, during the stdenv bootstrap, bison
gets built 6 (!) times.)
Many nodePackages have identical names as "normal" packages (e.g.,
swig, redis, tar) which is obviously bad. So don't make nix-env
recursive into nodePackages.
A better solution would be to have node packages have a "node-"
prefix, similar to Perl and Python packages.
All JARs in $pkg/share/java (for each $pkg in the build inputs) are
added to $CLASSPATH. Thus, you can say
buildInputs = [ setJavaClassPath someJavaDependency ];
and the JARs in someJavaDependency will be found automatically by
tools like javac or ant.
Note that the manual used to say that JARs should be installed in
lib/java; this is now share/java, following the Debian policy:
http://www.debian.org/doc/packaging-manuals/java-policy/x110.html
The directory share/java makes more sense because JARs are
architecture-independent. (Also, a quick grep shows that we were not
exactly consistent about this in Nixpkgs.)
This is a second attempt at unifying the generic and manual-config
kernel builds (see #412 for the last time).
The set of working kernel packages is a superset of those that work on
master, and as the only objection last time was the size of the $dev
closure and now both $out and $dev combined are 20M smaller than $out on
master (see message for ac2035287f), this
should be unobjectionable.
Signed-off-by: Shea Levy <shea@shealevy.com>
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
Also, Ant no longer has a build-time dependency on a particular JDK.
It finds the JDK via $JAVA_HOME or $PATH (by looking up javac). This
way, we don't need to have separate packages like apacheAntOpenJDK and
apacheAntOracleJDK. It also seems reasonable: after all, installing
GNU Make doesn't give you a C compiler either. It does mean that
instead of
buildInputs = [ ant ];
you now need to write something like
buildInputs = [ ant jdk ];
This unifies the "openjdk" and "openjre" packages. The JDK is placed
in the "out" output, the JRE in "jre".
Also, everything is now stored in $prefix/lib/openjdk, so the JDK/JRE
no longer pollute user environments with files like
"ASSEMBLY_EXCEPTION" at top-level.
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).
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>
