Since PostgreSQL 9.4 it's possible to build with different uuid
libraries. Eversince, the postgres docs [1] have this to say:
[..] the OSSP UUID library [..] is not well maintained, and is
becoming increasingly difficult to port to newer platforms. [..]
On Linux, OS X, and some other platforms, suitable functions are
provided in the libuuid library, which originally came from the
e2fsprogs project (though on modern Linux it is considered part of
util-linux-ng).
Using e2fs for Darwin was introduced 9 years ago in #8574, which library
to use for Linux was never considered again. Thus, start building with
newer libs now.
As a side effect, we require one less patch if we decide to build with
meson later.
[1]: https://www.postgresql.org/docs/current/uuid-ossp.html
doCheck was enabled in #61395 which does not mention an explicit decision
for "check" instead of "check-world". The latter runs more tests, for example
for contrib modules etc. - but results in higher build times..
Running "nix-build -A postgresql":
- with doCheck = false: 46s
- with checkTarget = "check": 60s
- with checkTarget = "check-world": 75s
/bin/locale doesn't exist on musl and was already effectively disabled
in #228349. However this still leaves the following warning for initdb:
performing post-bootstrap initialization ... sh: locale: not found
By applying the alpine patch to disable locale -a entirely, this warning
will disappear. This will also make one more regression test pass when
testing "check-world" instead of "check", only.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
The withPackages scope now provides a "postgresqlTestExtension" helper
which removes all the boilerplate for those kind of tests.
This was Mario Rodas' idea in #299756.
This fixes some build systems which look up the location of pg_config
via the location of the postgres binary itself, e.g. timescaledb,
instead of calling pg_config which is on PATH.
Since the -dev output is correctly placed before the default output of
postgresql in PATH, we can rely on that and call "pg_config" from the
default output's fake script. Only do that, when the one on PATH is
actually a different file, though, to prevent infinite loops.
Resolves#341408
We introduced LTO in #294504. At that time, we still needed to use LLVM
/ lld to make this work on darwin. For this to work for extensions, they
would need to set CFLAGS=-fuse-ld=lld, too. However, since #307880
landed, we don't need to do this anymore in the first place, LTO just
works out of the box on darwin.
Resolves#342362
This was supposed to happen in #294504, but the commit was accidentally
left out when splitting off some libpq-related changes. Originated in
#179962, by Sandro.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
