1.66 changes in layout suffix seems to break cmake finder

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list
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...

Stephan


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list



On 8 January 2018 at 16:14, Stephan Menzel via Boost-users <[hidden email]> 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

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


 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list


On 8 January 2018 at 16:36, Klaim - Joël Lamotte <[hidden email]> wrote:

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


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

 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Mon, Jan 8, 2018 at 4:36 PM, Klaim - Joël Lamotte via Boost-users <[hidden email]> 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

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



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list
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.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list
On Mon, Jan 8, 2018 at 11:37 PM, Gavin Lambert via Boost-users <[hidden email]> 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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list


On 9 January 2018 at 08:29, Stephan Menzel via Boost-users <[hidden email]> wrote:
On Mon, Jan 8, 2018 at 11:37 PM, Gavin Lambert via Boost-users <[hidden email]> 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


 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.66 changes in layout suffix seems to break cmake finder

Boost - Users mailing list
On Tue, Jan 9, 2018 at 11:13 AM, Klaim - Joël Lamotte <[hidden email]> wrote:

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


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users