This is a reversed patch of https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6426.
_CURRENT_OSX_VERSION isn't set properly, which causes this condition to fail,
which means we don't get CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG which means
we can't compile libcxx. Ugh.
Adds the SystemConfiguration framework to buildInputs unless we're
bootstrapping.
For the bootstrap version, we revert
31f631a142
instead so CMake builds without SystemConfiguration.
cmake on darwin now depends on the SystemConfiguration framework.
Support for this has not yet been added to our bootstrapping.
We need to decide how to go further. As this is blocking staging-next
it is reverted.
This reverts commit 29bbaa1489.
Also removing a comment that instructs maintainers to cross-check
the hash with one that is posted upstream, because as @lilyball
reasoned:
"I'm not really sure what the benefit of comparing the hash is; if the
download is tampered with, the hash is served from the same site and
would presumably be tampered with as well, and the download is done over
https and declares its Content-Length so there's no risk of truncation
(which would cause the file to fail to unpack anyway)"
By default, the cmake derivation contains the documentation in .rst
format. This format is not well suited for interactive use. Therefore,
we add both man and info outputs and convert the documentation to
these formats using Sphinx.
These formats are enabled by default only in cmake versions for
interactive use (ncurses, Qt), because using Sphinx in the basic
version leads to circular dependency (infinite recursion). Namely,
Sphinx has imagemagick in its checkInputs and imagemagick has several
transitive dependencies, which have cmake in nativeBuildInputs.
This `substituteInPlace` was introduced in 2016 when cmake was at v3.4:
* https://github.com/NixOS/nixpkgs/commit/5286c0aebb
In 2018 cmake v3.12.0 changed the code to make it not match anything:
* https://github.com/Kitware/CMake/commit/50b5e9ed13
```
substituteStream(): WARNING: pattern '${PYTHON_EXECUTABLE}' doesn't match anything in file 'Modules/FindCxxTest.cmake'
```
Having it around in 2021 with cmake v3.19.3 doesn't help,
and tests are disabled anyway.
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)
