Fixes missing CoreFoundation declarations since bump to 3.19.3,
e.g. `error: unknown type name 'CFUUIDRef'`
ApplicationServices.h transitively includes CoreFoundation.h, but as we
patch ApplicationServices out of CMake, the CF symbols were not visible.
Previously this was not a concern, as they were not needed until
d250b67722
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This fixes issues with building LibreSSL, which is required for the
NixOS tests: https://cmake.org/cmake/help/latest/release/3.19.html#id1
> CMake 3.19.0 compiles source files with the `LANGUAGE` property by
> passing an explicit language flag such as -x c. This is consistent
> with the property’s documented meaning that the source file is written
> in the specified language. However, it can break projects that were
> using the property only to cause the specified language’s compiler to
> be used. This has been reverted to restore behavior from CMake 3.18
> and below.
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
- OpenSSL is evidentally an optional dep. I guess pkg-config found it
before because it was a transitive dep?
- `zstd` and cross-built CMake can get by with a `cmakeMinimal that we
use during bootstrapping, so let's restrict to that.
pkg-config now has a target-sensative wrapper. We shouldn't rebuild
CMake because that wrapper changes. The setup hook should also be a
build time dep.
Fix #99325
The docdir flag needs to include `PROJECT_NAME` according to [GNU guidelines]. We are passing
`-DCMAKE_INSTALL_DOCDIR=${!outputDoc}/share/doc/${shareDocName}` but `$shareDocName` was unset.
The `multiple-outputs.sh` setup hook actually only defines `shareDocName` as a local variable
so it was not available for cmake setup hook. Making it global would be of limited usability,
since it primarily tries to extract the project name from configure script.
Additionally, it would not be set because the setup hook defines `setOutputFlags=`,
preventing the function defining `shareDocName` from running. And lastly, the function
would not run for single-output derivations.
Previously, we tried [not disabling `setOutputFlags`] and passing the directory flags
only for multi-output derivations that do not disable `setOutputFlags` but that meant having
two different branches of code, making it harder to check correctness. The multi-output
one did in fact not work due to aforementioned undefined `shareDocName`. It also broke
derivations that set `setOutputFlags=` like [`qtModule` function does] (probably
because some Qt modules have configure scripts incompatible with `configureFlags` defined
by `multiple-outputs.sh` setup hook). For that reason, it was [reverted], putting us back to start.
Let’s try to extract the project name from CMake in the cmake setup hook.
CMake has a `-L` flag for dumping variables but `PROJECT_NAME` did not seem to be among them
when I tested, so I had to resort to parsing the `CMakeLists.txt` file.
The extraction function is limited, it does not deal with
* project name on different line from the `project(` command opening
- that will just not get matched so we will fall back to
using the derivation name
* variable interpolation
- we will just fall back to using derivation name when the extracted
`project_name` contains a dollar character
* multiple [`project`] commands
- The command sets `PROJECT_NAME` variable anew with each call, so the
last `project` call before `include(GNUInstallDirs)` command will be used
when the included module would [cache the `CMAKE_INSTALL_DOCDIR` variable].
We will just take the first discovered `project` command for simplicity.
Hopefully, there are not many projects that use multiple `project` calls
before including `GNUInstallDirs`.
In either case, we will have some subdirectory so the conflicts will be minimized.
[GNU guidelines]: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#index-docdir
[not disabling `setOutputFlags`]: be1b22538a
[`qtModule` function does]: https://github.com/NixOS/nixpkgs/pull/12740
[reverted]: https://github.com/NixOS/nixpkgs/pull/92298
[`PROJECT_NAME`]: https://cmake.org/cmake/help/v3.18/variable/PROJECT_NAME.html
[`project`]: https://cmake.org/cmake/help/v3.18/command/project.html
[cache the `CMAKE_INSTALL_DOCDIR` variable]: 92e30d576d/Modules/GNUInstallDirs.cmake (L298-L299)
This reverts commit be1b22538a.
The commit broke Qt modules using CMake because they disable setOutputFlags.
There is no need to have these flags limited to multiple output derivations since it
should just work. If it does not, it is a bug that should be fixed as per
https://github.com/jtojnar/cmake-snips#assuming-cmake_install_dir-is-relative-path
Likewise, having a variable to disable passing the flags is also unnecessary,
since CMake, unlike some configure scripts, ignores unknown flags. And if a person
does not like the values, they can just override them by passing the offending
flag with a different value to cmakeFlags.
This brings cmake inline with the behaviour used for configure
scripts, defined in multiple-outputs.sh. It's important because
that setup hook will only set shareDocName if multiple outputs are in
use (and setOutputFlags hasn't been disabled). So previously,
CMAKE_INSTALL_DOCDIR would be set to $out/share/doc for single-output
derivations, instead of $out/share/doc/$shareDocName, which would
result in collisions.
Since this hook now uses the setOutputFlags variable, I had to remove
the empty assignment of it added in
a714284d8b.
Fixes: https://github.com/NixOS/nixpkgs/issues/82304
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
