-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.70 Breaks My Cmake Builds #75
Comments
Yes, those files are work in progress and are supposed to be used when you include Boost libraries into your CMake project tree. There may be missing support from some of the libraries, maybe some of them are referenced from Boost.Log CMakeLists.txt. I don't intend to fix that, instead the missing support should be added to dependent libraries. Until this is done, feel free to ignore Boost.Log CMakeLists.txt.
I'm not sure what this means. The CMakeLists.txt in Boost.Log has no effect on package lookup if you don't include it. Obviously, the built-in CMake find_package implementation is not supported or affected by Boost. There is also new Boost superproject feature that allows to generate config files for CMake. I'm not familiar with how those work or how compatible they are with the CMake built-in find_package. In any case, that functionality is part of Boost superproject, not the particular libraries. If it is those config files you're having the problem with, please report it here. |
That's really odd. It seemed like somehow the boost cmake files were being found despite me making no effort to include them in my build. I wonder if it's something going on over on the cmake side of things. I gave them a heads-up too, since the whole thing took me a few hours to figure out what was going on (As far as I did before reverting back to boost 1.69.) Cmake has a bunch of variables that get set during the build process. So if I tell it to find some boost components, it'll go figure out the cflags, link libraries and all that stuff. So all the link libraries get put in one called Boost_LIBRARIES, which is typically how I've been linking them in my builds. Since that mechanism seems to be canonical, it probably shouldn't be disrupted. If I have some free time this weekend, I'll try to investigate further. If I come up with anything useful, I'll put up a pull request. Thanks! |
Sorry for the confusion, but I forgot that I had removed CMakeLists.txt from Boost.Log a while ago. If you update to the latest develop, you should no longer have it and it won't affect your build. If you still have the problem then then it is clearly caused by something else. |
This is how the built-in implementation of find_package for Boost worked (i.e. from FindBoost CMake package). I'm not sure that's how the config files generated by the superproject (or, more precisely, the |
This work also broke the Apache Thrift build process since msys2 included cmake 3.14.2 and boost 1.70.0. Variables like Boost_INCLUDE_DIRS are no longer set. Libraries that used to be included automatically are no longer included. This is a bit of a mess... |
What work? |
The Boost CMake modules included in cmake 3.14.2 which I had thought came out of this work, perhaps not. I did find that I can disable it and get the old behavior, so that's good. I'm unblocked on that one. |
I've spent hours trying to get 1.70, 1.71, and 1.72 to work. |
As of 1.70, boost in github breaks my cmake builds. This is not an issue in 1.69. It seems like boost now includes a bunch of cmake config files. Among other things, Boost_LIBRARIES from findboost no longer gets set, and boost::log does not find a library (causing the cmake to fail) unless BUILD_SHARED_LIBS is set to ON. It's not a huge problem for what I'm doing at the moment, but I imagine it could cause some trouble once more people start using this version.
The text was updated successfully, but these errors were encountered: