After making multiple outputs in the mesa_glu package the headers are
not included in the mesa attribute. The attached patch puts them in it.
From ced24208a300bea8234e7898ae6fec34fbd67289 Mon Sep 17 00:00:00 2001
From: Karn Kallio <kkallio@skami.org>
Date: Thu, 1 Sep 2016 16:18:23 -0400
Subject: [PATCH] mesa: Add the mesa glu headers to the mesa attribute.
We now have a newer version and the older version didn't work anymore
anyway because it depended on sqlalchemy7 which was itself broken,
because it depended on an older version of sqlite.
- Add support for python bindings
- make neuron respect standard pythonpath prefix
- force exec_prefix == prefix to respect standard nix file hierarchy
- normalize indentation
- propagate dependencies necessary for nrniv_makefile usage
- Add support for darwin
This was one of the ways to build packages, we are trying
hard to minimize different ways so it's easier for newcomers
to learn only one way.
This also:
- removes texLive (old), fixes#14807
- removed upstream-updater, if that code is still used it should be in
separate repo
- changes a few packages like gitit/mit-scheme to use new texlive
With the default kernel and thus with the build I have tested in
74ec94bfa2, we get an error during
modules_install:
make[2]: execvp: /nix/store/.../bin/bash: Argument list too long
I haven't noticed this build until I actually tried booting using this
kernel because make didn't fail here.
The reason this happens within Nix and probably didn't yet surface in
other distros is that programs only have a limited amount of memory
available for storing the environment and the arguments.
Environment variables however are quite common on Nix and thus we
stumble on problems like this way earlier - in this case Linux 4.8 - but
I have noticed this in 4.7-next as well already.
The fix is far from perfect and suffers performance overhead because we
now run grep for every *.mod file instead of passing all *.mod files
into one single invocation of grep.
But comparing the performance overhead (around 1s on my machine) with
the overall build time of the kernel I think the overhead really is
neglicible.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
