1.66 changes in layout suffix seems to break cmake finder
bjam.exe --layout=versioned variant=release address-model=64
Hello, I am currently trying to upgrade my projects to 1.66 and I am puzzled by a change in bjam's 'laout' parameter. I am building boost for MSVC14 (x64). Normally I use the following command line: link=static,shared runtime-link=shared threading=multi stage to achieve the build flags and setup that I need. Up until 1.65 this yielded libs named like: libboost_atomic-vc140-mt-1_65.lib This is what appears to be the most flexible for my use case and I always discover them using the 'normal' CMake finders like this: set(BOOST_ROOT ${WHERE_MY_THIRD_PARTY_STUFF_IS}/boost-1.66.0 CACHE PATH "set root of boost install") set(BOOST_INCLUDEDIR ${BOOST_ROOT}/include CACHE PATH "set boost includes") set(BOOST_LIBRARYDIR ${BOOST_ROOT}/lib CACHE PATH "set boost library dir") set(Boost_ADDITIONAL_VERSIONS "1.66.0") find_package(Boost REQUIRED COMPONENTS ...) Now over the years the meaning of the --layout parameter and its defaults have occasionally changed by I always managed to get something like this. But now, with 1.66 the filenames are changed to that: libboost_atomic-vc140-mt-x64-1_66.lib With this, CMake won't find the libs anymore. I have tried all different variantions of --layout I know (system, tagged, versioned) but I cannot get the old naming scheme back. I could rename the files manually but I am a bit afraid that this might break some linker (autolink) magick and also it doesn't seem right. Trying with several CMake finder options also got me nowhere. Using layout system is not desired as I like to quickly distinguish between versions on sight. So my question is: Is there a way to get >=1.66 to build with the filename scheme it had until now? Or is there a change to the CMake finders that will fix this? Thanks for any suggestions... Stephan
On 8 January 2018 at 16:14, Stephan Menzel via Boost-users < boost-users@lists.boost.org> wrote:
Hello,
I am currently trying to upgrade my projects to 1.66 and I am puzzled by a change in bjam's 'laout' parameter.
I am building boost for MSVC14 (x64). Normally I use the following command line:
bjam.exe --layout=versioned variant=release address-model=64 link=static,shared runtime-link=shared threading=multi stage
to achieve the build flags and setup that I need. Up until 1.65 this yielded libs named like:
libboost_atomic-vc140-mt-1_65.lib
This is what appears to be the most flexible for my use case and I always discover them using the 'normal' CMake finders like this:
set(BOOST_ROOT ${WHERE_MY_THIRD_PARTY_STUFF_IS}/boost-1.66.0 CACHE PATH "set root of boost install") set(BOOST_INCLUDEDIR ${BOOST_ROOT}/include CACHE PATH "set boost includes") set(BOOST_LIBRARYDIR ${BOOST_ROOT}/lib CACHE PATH "set boost library dir") set(Boost_ADDITIONAL_VERSIONS "1.66.0")
find_package(Boost REQUIRED COMPONENTS ...)
Now over the years the meaning of the --layout parameter and its defaults have occasionally changed by I always managed to get something like this.
But now, with 1.66 the filenames are changed to that:
libboost_atomic-vc140-mt-x64-1_66.lib
With this, CMake won't find the libs anymore. I have tried all different variantions of --layout I know (system, tagged, versioned) but I cannot get the old naming scheme back. I could rename the files manually but I am a bit afraid that this might break some linker (autolink) magick and also it doesn't seem right. Trying with several CMake finder options also got me nowhere. Using layout system is not desired as I like to quickly distinguish between versions on sight. So my question is: Is there a way to get >=1.66 to build with the filename scheme it had until now? Or is there a change to the CMake finders that will fix this?
Thanks for any suggestions...
Indeed CMake's FindBoost module needs to be uprgaded to be able to find libs with the new name layout (although it needs to be upgraded each time there is a boost release anyway...) I would recommand trying this patch which is imminent to be merged in CMake (just remplace your local FindBoost.cmake found in your CMake install dir): https://gitlab.kitware.com/cmake/cmake/merge_requests/1625 Here is the related discussion: https://gitlab.kitware.com/cmake/cmake/issues/17575 This mean to use the usual find_package( Boost ... ) instead of manually do the discovery. Just specify BOOST_ROOT in CMake cli to specify the root directory of your Boost install. A. Joël Lamotte
On 8 January 2018 at 16:36, Klaim - Joël Lamotte
I would recommand trying this patch which is imminent to be merged in CMake (just remplace your local FindBoost.cmake found in your CMake install dir): https://gitlab.kitware.com/cmake/cmake/merge_requests/1625 Here is the related discussion: https://gitlab.kitware.com/cmake/cmake/ issues/17575
Alternatively you can just wait for the next version of CMake. Anyway note that the search for the right architecture tag might not be trivial depending on how many different platforms which is why I recommand this version of FindBoost that does the trick, but you could also just extract the wanted logic from there and put it where you want. A. Joël Lamotte
On Mon, Jan 8, 2018 at 4:36 PM, Klaim - Joël Lamotte via Boost-users < boost-users@lists.boost.org> wrote:
Indeed CMake's FindBoost module needs to be uprgaded to be able to find libs with the new name layout (although it needs to be upgraded each time there is a boost release anyway...) I would recommand trying this patch which is imminent to be merged in CMake (just remplace your local FindBoost.cmake found in your CMake install dir): https://gitlab.kitware.com/cmake/cmake/merge_requests/1625 Here is the related discussion: https://gitlab.kitware.com/cmake/cmake/ issues/17575
Hello Joël, thank you for your response. Patching CMake however seems a bit much, especially the finder scripts. I was hoping for a less intrusive version. I am reluctant because I maintain those projects over at least 5 different architectures, some of which have older (3.4.x) CMake versions installed and I can't even be sure they will work with a 3.10.x finder script. Sure, I could manually build CMake there as well but it all seems so unnecessary, given that it's just a strange file naming scheme change. I would not agree that CMake needs upgrading for every new boost version. During the last years I was going pretty well with the scheme I had and even old CMakes could easily find it provided I used set(Boost_ADDITIONAL_VERSIONS "1.66.0") ... which I think is what you are referring to. I will try the patched finder though as a last resort. Best regards... Stephan
On 9/01/2018 05:08, Stephan Menzel wrote:
Sure, I could manually build CMake there as well but it all seems so unnecessary, given that it's just a strange file naming scheme change. The naming change was intentional to allow 32-bit and 64-bit libraries to be built in one pass and to live in the same output directory.
The latter is a common deployment requirement on Windows when shipping both 32-bit and 64-bit executables, which previously required workarounds such as using custom build ids or moving files to separate directories, and also required building Boost twice with different options.
On Mon, Jan 8, 2018 at 11:37 PM, Gavin Lambert via Boost-users < boost-users@lists.boost.org> wrote:
The naming change was intentional to allow 32-bit and 64-bit libraries to be built in one pass and to live in the same output directory.
The latter is a common deployment requirement on Windows when shipping both 32-bit and 64-bit executables, which previously required workarounds such as using custom build ids or moving files to separate directories, and also required building Boost twice with different options.
Hello Gavin, I don't doubt this is intentional but was puzzles me is the apparent lack of backwards compatibility. When breaking changes like these are introduced, I would normally expect some kind of switch to temporarily restore old behavior to give people a chance to adopt. Don't get me wrong, but this doesn't feel quite 'Boost' to me. I am currently trying to work with a manual rename and switch of as much autolink magick as possible. See how that rolls. Best regards... Stephan
On 9 January 2018 at 08:29, Stephan Menzel via Boost-users < boost-users@lists.boost.org> wrote:
On Mon, Jan 8, 2018 at 11:37 PM, Gavin Lambert via Boost-users < boost-users@lists.boost.org> wrote:
The naming change was intentional to allow 32-bit and 64-bit libraries to be built in one pass and to live in the same output directory.
The latter is a common deployment requirement on Windows when shipping both 32-bit and 64-bit executables, which previously required workarounds such as using custom build ids or moving files to separate directories, and also required building Boost twice with different options.
Hello Gavin,
I don't doubt this is intentional but was puzzles me is the apparent lack of backwards compatibility. When breaking changes like these are introduced, I would normally expect some kind of switch to temporarily restore old behavior to give people a chance to adopt. Don't get me wrong, but this doesn't feel quite 'Boost' to me. I am currently trying to work with a manual rename and switch of as much autolink magick as possible. See how that rolls.
If my understanding is correct, even if the default layout changed, the previous layout is still there so you can use the "--layout=<layout>" option of Boost 1.66's b2, which I just realized is not documented online yet, so just look at the help info. I'm not totally sure but I think you need "versioned" layout to get the previous layout. A. Joël Lamotte
On Tue, Jan 9, 2018 at 11:13 AM, Klaim - Joël Lamotte
If my understanding is correct, even if the default layout changed, the previous layout is still there so you can use the "--layout=<layout>" option of Boost 1.66's b2, which I just realized is not documented online yet, so just look at the help info. I'm not totally sure but I think you need "versioned" layout to get the previous layout.
Well, sadly not. I always specify the layout manually for the different platforms and for Windows I normally choose "versioned" so that I get the desired scheme. Since 1.66 ,"versioned" yields this different result. Anyway, manually renaming the files and disabling all autolinking did the trick and I can now use stock CMake again to locate the libraries. As long as I am fully static that is. Thanks everyone! Best regards... Stephan
participants (3)
-
Gavin Lambert -
Klaim - Joël Lamotte -
Stephan Menzel