Cmake paths patch 1/? (boost, aws-sdk-cpp) #85254
Conversation
AWS's SDK by default tries to prepend its install root to each of the library paths; this obviously fails with the absolute paths that Nix gives it. Worse, it computes the installation root by walking up the filesystem from its cmake file, so even if the AWSSDK_ROOT_DIR is explicitly set to the root directory, it gets replaced with the path to the derivation's dev output. This is all fixed with a patch to the cmake files that generate the installed configuration. Once this is fixed, it *still* doesn't work because the export generator built into cmake insists on adding `$out/include` to the header search path; when importing this configuration in another package, cmake will fail because `$out/include` doesn't exist (After all, it was relocated by a fixup hook). A small postFixupHook will recreate the directory and make cmake happy.
Boost generates its installed cmake configuration using custom logic in its own build system; while this logic *knows* where it should be installed, the generated config overrides the correct information with new paths based on the location of the cmake configuration file in an attempt to let the package be relocated after installation. This patch simply undoes that.
|
This looks useful! @thequux, do you think these patches or parts of them can be sent upstream? |
|
The aws-cpp-sdk one can be; it's designed to mangle the logic as little as possible. However, the boost patch is very nix-specific; bjam is not exactly my jam, so I didn't try to do a nice job of it, but rather make something that would be robust to upstream changes. |
|
@thequux Could you please do that? The reason for upstreaming patches (especially bigger ones like the one you add to |
|
Sure. I'll send a patch for aws-sdk-cpp first thing tomorrow morning, but for boost, I need to first verify that we're actually giving bjam all of the correct paths at build time, rather than depending on the preFixup hook to move things into the correct output. |
|
I submitted a slightly improved version of the patch in aws/aws-sdk-cpp#1365 ; the differences between this patch and that one are irrelevant for Nix's purposes (specifically, the upstream patch will generate valid pkg-config files even if the install dirs aren't absolute). I get the impression that the AWS SDK hasn't been focusing much on pull requests recently, as upstream hasn't touched any PRs since 6 Jan, so it may be best to use an in-tree patch until they get through their backlog. |
|
Just wanted to say that both this and #73940 work, as mentioned in #85922 . What I've found out today though, was that with the workaround supplied at: #85922 (comment) Makes (e.g) |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Thanks for doing this! I had stumbled on the broken aws-sdk-cpp pcfiles a while ago, but hacked it up with a local overlay fix using I've built and verified this fixes the issue; can you send a backport PR to 20.03 as well? Separately, it'd be nice if we had some kind of automated pkg-config file validation check, like making sure includedirs and libdirs actually exist, which would fail the build if not. |
Motivation for this change
Many packages generate CMake configuration files that try to figure out the paths to include and library directories from the location of the CMake file; this breaks in NixOS derivations with a
devoutput because the CMake package gets installed to$out/lib/cmake, but then gets moved into thedevoutput by the_multioutDevsfixup hook.This needs to be fixed on a case-by-case basis, because this usually involves custom logic. So far, I've fixed boost (>= 1.70; before that, it didn't install cmake files as far as I can tell) and aws-sdk-cpp.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"(I hoped Hydra would do that for me)./result/bin/) (no binaries, only libraries, and they should be unaffected)nix path-info -Sbefore and after)(within 10KiB for both)