Feature/cmake-config merged to develop; yml files need to be updated
I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost. Unfortunately, this change adds two necessary submodules to the superproject, `tools/boost_install` and `libs/headers`. As a result, all .travis.yml and appveyor.yml files that rely on a partial checkout need to be updated to perform git submodule update --init tools/boost_install git submodule update --init libs/headers in addition to the usual git submodule update --init tools/build git submodule update --init libs/config I'm sorry for the inconvenience this will cause, or perhaps already has caused.
On 12/18/18 9:09 PM, Peter Dimov via Boost wrote:
I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost.
Does this remove the necessity of the CMakeLists.txt files that were added recently to multiple libraries?
Unfortunately, this change adds two necessary submodules to the superproject, `tools/boost_install` and `libs/headers`. As a result, all .travis.yml and appveyor.yml files that rely on a partial checkout need to be updated to perform
git submodule update --init tools/boost_install git submodule update --init libs/headers
in addition to the usual
git submodule update --init tools/build git submodule update --init libs/config
I'm sorry for the inconvenience this will cause, or perhaps already has caused.
Yeah, it has...
Gesendet: Dienstag, 18. Dezember 2018 um 19:22 Uhr Von: "Andrey Semashev via Boost"
On 12/18/18 9:09 PM, Peter Dimov via Boost wrote:
I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost.
Does this remove the necessity of the CMakeLists.txt files that were added recently to multiple libraries?
Best I can tell no: The new functionality is about cmake users being easily able to consume the output of b2 install, whereas my pull requrest are about directly building and consuming local copies of boost libraries as part of a cmake project via add_subdirectory( <boost-lib> ), thus making sure everything is build with the same settings. I think the main advantage of the new functionality is that the cmake people don't have to manually update their FindBoost script everytime boost name mangling has changed or additional libraries have been added. Which also means you don't need an up-to date cmake version in order to correctly find the latest boost libraries. Best Mike
Andrey Semashev wrote: On 12/18/18 9:09 PM, Peter Dimov via Boost wrote:
These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost.
Does this remove the necessity of the CMakeLists.txt files that were added recently to multiple libraries?
No, it's a separate thing. These configuration files are installed as part of issuing `b2 install` from a release. So you get the headers in /usr/local/include, the libraries in /usr/local/lib, and the configuration files in /usr/local/lib/cmake (assuming the default prefix of /usr/local/). This Boost installation is then used from CMake via find_package like f.ex. https://github.com/boostorg/boost_install/blob/develop/.travis.yml#L59 https://github.com/boostorg/boost_install/blob/develop/test/filesystem/CMake... The CMakeLists.txt files, on the other hand, are used with a different workflow; you download/submodule the libraries from Github into subdirectories of your project, and then use them from CMake with add_subdirectory. Like f.ex. https://github.com/boostorg/mp11/blob/develop/.travis.yml#L248 https://github.com/boostorg/mp11/blob/develop/test/cmake_subdir_test/CMakeLi...
On Tue, 18 Dec 2018, 19:40 Peter Dimov via Boost Andrey Semashev wrote:
On 12/18/18 9:09 PM, Peter Dimov via Boost wrote: These configuration files enable a Boost installation to be used from
CMake via `find_package(boost_filesystem)`, without relying on
FindBoost. Does this remove the necessity of the CMakeLists.txt files that were
added
recently to multiple libraries? No, it's a separate thing. So, it's dor Boost consumers, not developers. Good. Thanks for the efforts.
--
Mateusz Loskot, mateusz@loskot.net
(Sent from mobile)
On Tue, Dec 18, 2018 at 1:19 PM Peter Dimov via Boost
I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost.
Unfortunately, this change adds two necessary submodules to the superproject, `tools/boost_install` and `libs/headers`. As a result, all .travis.yml and appveyor.yml files that rely on a partial checkout need to be updated to perform
git submodule update --init tools/boost_install git submodule update --init libs/headers
in addition to the usual
git submodule update --init tools/build git submodule update --init libs/config
I'm sorry for the inconvenience this will cause, or perhaps already has caused.
If one uses tools/boostdep and runs depinst, will it pull those in automatically? I manually pull in tools/boostdep, tools/build, and tools/inspect, and then run depinst to pull in all the direct and transitive dependencies. - Jim
James E. King III wrote:
If one uses tools/boostdep and runs depinst, will it pull those in automatically?
No, it doesn't. Although we do need a mechanism to pull those "essential submodules" automatically. I'm thinking of having a file named .essentials in the root, so that we can then do git submodule init `cat .essentials` git submodule update in .travis.yml.
I manually pull in tools/boostdep, tools/build, and tools/inspect, and then run depinst to pull in all the direct and transitive dependencies.
tools/inspect should no longer be necessary. It was a mistake that Jamroot required it, and that was fixed.
On Wed, Dec 19, 2018 at 2:37 PM Peter Dimov via Boost
James E. King III wrote:
If one uses tools/boostdep and runs depinst, will it pull those in automatically?
No, it doesn't. Although we do need a mechanism to pull those "essential submodules" automatically. I'm thinking of having a file named .essentials in the root, so that we can then do
git submodule init `cat .essentials` git submodule update
in .travis.yml.
I manually pull in tools/boostdep, tools/build, and tools/inspect, and then run depinst to pull in all the direct and transitive dependencies.
tools/inspect should no longer be necessary. It was a mistake that Jamroot required it, and that was fixed.
Thanks - fortunately for any repository using boost-ci already, the submodule updates were previously factored out into an external script. I just updated boost-ci with the changes from your original email. This fixes the CMT repositories, plus function, move, signals2, date_time, format, and uuid. - Jim
participants (5)
-
Andrey Semashev -
James E. King III -
Mateusz Loskot -
Mike -
Peter Dimov