with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
See docs.
Follow-up work:
- Existing packages should be converted
- `defaultPkgConfigPackages` should assert on `meta.pkgConfigModules`
and let `tests.pkg-config` alone test the build results.
CC @sternenseemann
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
This improves what commit
e999def1 zlib: clean up static/shared distincion
described as "kind of a mess" and "confusing". And indeed it was confusing.
Now, the concept whether or not the .a file is moved to a split output
is controlled by a clean variable.
The defaults remain unchanged.
The new approach also finally cleanly allows building statically but NOT
using a split output, like all other autoconf-based projects in nixpkgs do
(using the `dontDisableStatic` setting).
That is important for overlays that want to enable static libs for all
packages in one go, without having to hand-patch idiosynchrasies like zlib
had until now.
Until now, if you wanted the .a in the main output, the only way was to go via
`static=false, shared=true` -- which made no sense, because you had to say
`static=false` even though you want a static lib. That is fixed now.
The main explanation was taken from commit:
e999def1 zlib: clean up static/shared distincion
The `SHARED_MODE=1` bit was originally introduced in commit:
0bfc84b0 Cross-compile zlib for Windows
This is kind of a mess, but basically:
- static=true, shared=true means to build statically but move it to
the static output
- static=true, shared=false means to build statically and leave it in
the main output
- static=false, shared=true means to not build static at all
Confusingly, the old default was static=true, shared=true even though
static=false? Still can’t figure out what was meant by that.
1. CHOST is how one specifies the cross host platform with this
non-standard configure script. We were just getting lucky with Linux
cross.
2. install_name_tool needs the the binutils prefix.
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
