1.70 Breaks My Cmake Builds about log HOT 8 CLOSED

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.

from log.

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!

from log.

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.

from log.

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.

from log.

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

from log.

This work also broke the Apache Thrift build process

What work?

from log.

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.

from log.

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.

from log.