Skip to content
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

Closed
FlyingRhenquest opened this issue Jan 31, 2019 · 8 comments
Closed

1.70 Breaks My Cmake Builds #75

FlyingRhenquest opened this issue Jan 31, 2019 · 8 comments

Comments

@FlyingRhenquest
Copy link

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.

@Lastique
Copy link
Member

Lastique commented Feb 1, 2019

It seems like boost now includes a bunch of cmake config files.

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.

Among other things, Boost_LIBRARIES from findboost no longer gets set

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.

@Lastique Lastique closed this as completed Feb 1, 2019
@FlyingRhenquest
Copy link
Author

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!

@Lastique
Copy link
Member

Lastique commented Feb 1, 2019

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.

@Lastique
Copy link
Member

Lastique commented Feb 1, 2019

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.

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 boost_install submodule) work or intended to work.

@jeking3
Copy link

jeking3 commented May 4, 2019

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...

@Lastique
Copy link
Member

Lastique commented May 4, 2019

This work also broke the Apache Thrift build process

What work?

@jeking3
Copy link

jeking3 commented May 4, 2019

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.

@jdmairs
Copy link

jdmairs commented Dec 28, 2019

I've spent hours trying to get 1.70, 1.71, and 1.72 to work.
Even with this help issue I'm still not working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants