boost - apply defines to Boost::headers too #11217
Merged
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
|
All green in build 1 (
|
Hooks produced the following warnings for commit 7e68973boost/1.77.0boost/1.73.0boost/1.71.0boost/1.76.0boost/1.75.0boost/1.72.0boost/1.79.0boost/1.78.0boost/1.69.0boost/1.74.0boost/1.70.0 |
This was referenced Jun 22, 2022
|
I detected other pull requests that are modifying boost/all recipe: This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there. |
jwillikers
approved these changes
Jun 24, 2022
SSE4
approved these changes
Jun 27, 2022
danimtb
approved these changes
Jun 27, 2022
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.
Specify library name and version: boost/any version
I've mentioned a few past PRs in the hope that some boost-experts can weigh in on this PR.
I've done what I think is right, but I'm just a humble long time boost user.
Linking to Boost::headers only can still trigger autolink, even if the package had magic_autolink=False, because the no-auto-link define (BOOST_ALL_NO_LIB) was not set for the Boost::headers target.
This matters on the MSVC platform.
In my case, it was even more complicated. For MSVC:
My boost package had magic_autolink=False and layout=tagged (the default is versioned).
I had a library LibA that
#include <boost/atomic.hpp>in its public header, and linked PUBLIC Boost::headers PRIVATE Boost::atomicI had an exe in the same cmake project that linked to LibA.
The exe code was only set to link to Boost::headers (due to the PUBLIC link in LibA).
The exe code saw the boost/atomic header, and as Boost::headers target did NOT have the autolink or layout defines, it asked the linker to link with libboost_atomic_versionnum.lib which did not exist in the package/lib folder (I had built the "tagged" library name, not the "versioned" library name).
With this change, the exe code sees the BOOST_ALL_NO_LIB and does not autolink.
And interestingly, I was able to drop Boost::atomic from the link library list entirely ... the atomic features I was using did not require linking to the library at all !
I have added a bunch of notes into the recipe, perhaps they should be shortened or removed.
The boost recipe is very elaborate, so I felt it needed some explanation.
For reference, the definitions were added in the current state in #2097
I think this is a better solution to issue #5156, you should not have to decorate your CMakeList.txt with Boost::disable_autolinking if you have already specified magic_autolink=False. Not should you have to link to (eg) Boost::atomic just to prevent it from autolinking to the wrong {layout} library name.
There are other definitions I felt also needed to be added to Boost::headers,
like BOOST_LIB_DIAGNOSTIC, and BOOST_AUTO_LINK_{layout} as I already discussed above.
I also think BOOST_ALL_DYN_LINK should be added to the headers component, as I discuss in the recipe, you can have one library using only headers, and another linking to it that also links to the actual libraries. You don't want half your boost compiled assuming static linkage, and the other half assuming dynamic linkage. Nor do you want to have to link that first library to boost-libs just so you can get those definition flags.
I did not add the BOOST_STACKTRACE_* definitions to the headers, but I do wonder if they should be added anyway. Surely any definitions should always be set when using any part of boost, as it is a complicated beast and who knows when you will include a stacktrace header and will need those definitions?