Hack CMake to ignore the "build environment" prefix in its searches #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In [conda-forge GitHub issue conda-forge#24](conda-forge#24) there was a problem because CMake decided to link with a version of the ncurses library found in the "build environment" prefix, rather than the "host environment" -- the major versions were different and so the resulting binaries did not link against the major version intended in the recipe specification. As far as I can tell, the problem is that CMake decides that the "build environment" library directory should be searched for shared libraries, which is in turn because the build-env prefix shows up in the variable `CMAKE_SYSTEM_PREFIX_PATH`. We hack the CMakeLists.txt file to remove the relevant directory, which fixes the problem. As a bonus, a bunch of messages about libraries like `libz` being shadoweded between the build and host prefixes now go away. The [CMake docs](https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html) say that you're not supposed to futz with this variable, but I couldn't find an alternative solution. It may be fixable by patching our cmake package -- although I don't have a good sense as to whether we might sometimes want the build-env prefix to be in `CMAKE_SYSTEM_PREFIX_PATH`.
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In conda-forge GitHub issue #24 there was a problem because CMake decided to link with a version of the ncurses library found in the "build environment" prefix, rather than the "host environment" -- the major versions were different and so the resulting binaries did not link against the major version intended in the recipe specification.
As far as I can tell, the problem is that CMake decides that the "build environment" library directory should be searched for shared libraries, which is in turn because the build-env prefix shows up in the variable
CMAKE_SYSTEM_PREFIX_PATH. We hack the CMakeLists.txt file to remove the relevant directory, which fixes the problem. As a bonus, a bunch of messages about libraries likelibzbeing shadowed between the build and host prefixes now go away.The CMake docs say that you're not supposed to futz with this variable, but I couldn't find an alternative solution. It may be fixable by patching our cmake package -- although I don't have a good sense as to whether we might sometimes want the build-env prefix to be in
CMAKE_SYSTEM_PREFIX_PATH.Checklist
conda-smithy