Boost 1.72.0-p0 fails on Boost::boost about hunter

[daminetreg]

Ah okay, sorry for my misunderstanding so it's acutally the plan of @ruslo to not use the boost generated package config.

I saw in commit 7ca0ec0 that there are scripts to clean them up, the script just doesn't work anymore because they seem to have been renamed after the library name.

I tried a local build with hunter passing --no-cmake-config instead, and it works, so I will make a PR with this fix today. Still looking if I have not missed anything.

[daminetreg]

@michaeldkroener you can try for yourself locally if it works with :

include(HunterGate)
HunterGate(
    URL "https://github.com/nxxm/hunter/archive/feature/fix-boost-1.72-cmake-package-configs.zip"
    SHA1 "039b7abd220e4368d3fcbf7df520279678089cca"
)

Remove your hunter folder first perhaps, to avoid that the lying BoostConfig.cmake don't mistaken your cmake.

[noeffn]

Can confirm it works perfectly with the fix after removing the hunter folder.

[daminetreg]

I tried with cmake 3.16.2 and 3.13.4.... no problems ... can some body give me a hint what I did wrong?

Yes still, this is the same issue, I think it depends of the lexical sorting of directory names when cmakes hunts for the package-config.cmake files. In one case it finds the BoostConfig.cmake from boost and in the other where it works you happily end up with the FindBoost support.

By the way did you tried on which OS ? I even wonder if locale doesn't play a role when cmake traverses the directories.

I think the best way is to fix the wrong "path" in boost. Then we can use the config modul from boost and we have lesser to maintain to easier update to newest boost version...

Sure but one step at a time. If we wait for boost to accept our change or patch boost install cmakes in bjam in hunter it costs way more times before we can actually use boost 1.72.

It also needs a bigger effort and testing, to make cmakelists that worked previously with FindBoost to work with integrated boost cmake.

There are many things to be solved at the Boost cmake support, it's really only an early support that they deliver, and things that they do, like forcing shared library search is also a problem.

I will try to find the root cause of the "wrong path" and will create a PR in boost ....

I wanted to do the PR to the boost build repo whenever I get the time of it, but I'm happy someone else will tackle this ^^.

For the moment with the time I have for this I just wanted to ensure existing hunter based cmake builds further. Because it's not just that PATH, you will have many other compatibility issues.

[dan-42]

I will look into it.

@michaeldkroener
Can you pleasse give me more information about your setup?
Plattform, compiler version etc.

thx

[dan-42]

@michaeldroener what is strange, all the test did pass and Boost::boost is tested here:

https://github.com/cpp-pm/hunter/blob/master/examples/Boost/CMakeLists.txt#L16

[rbsheth]

@dan-42 Thanks for picking this up.

@michaeldkroener What toolchain are you using?

[CarloWood]

Boost 1.72 requires CMake 3.16.2 or newer.
See https://stackoverflow.com/questions/42123509/cmake-finds-boost-but-the-imported-targets-not-available-for-boost-version/42124857#42124857
Is your cmake new enough?

[daminetreg]

I wonder if the cmake version is really the issue, I see the Boost::headers / Boost::boost target being set to the Hunter Source extraction path, actually it should be on Install/include.

For example hunter generated for current released version Users/daminetreg/.hunter/_Base/b13c867/13d43d3/e844a7d/Install/lib/cmake/boost_headers-1.72.0/boost_headers-config.cmake

# Generated by Boost 1.72.0

if(TARGET Boost::headers)
  return()
endif()

if(Boost_VERBOSE OR Boost_DEBUG)
  message(STATUS "Found boost_headers ${boost_headers_VERSION} at ${boost_headers_DIR}")
endif()

# Compute the include and library directories relative to this file.

get_filename_component(_BOOST_CMAKEDIR "${CMAKE_CURRENT_LIST_DIR}/../" ABSOLUTE)

# If the computed and the original directories are symlink-equivalent, use original
if(EXISTS "/Users/daminetreg/.hunter/_Base/b13c867/13d43d3/e844a7d/Build/Boost/__filesystem/Install/lib/cmake")
  get_filename_component(_BOOST_CMAKEDIR_COMPUTED "${_BOOST_CMAKEDIR}" REALPATH)
  get_filename_component(_BOOST_CMAKEDIR_ORIGINAL "/Users/daminetreg/.hunter/_Base/b13c867/13d43d3/e844a7d/Build/Boost/__filesystem/Install/lib/cmake" REALPATH)
  if(_BOOST_CMAKEDIR_COMPUTED STREQUAL _BOOST_CMAKEDIR_ORIGINAL)
    set(_BOOST_CMAKEDIR "/Users/daminetreg/.hunter/_Base/b13c867/13d43d3/e844a7d/Build/Boost/__filesystem/Install/lib/cmake")
  endif()
  unset(_BOOST_CMAKEDIR_COMPUTED)
  unset(_BOOST_CMAKEDIR_ORIGINAL)
endif()

get_filename_component(_BOOST_INCLUDEDIR "${_BOOST_CMAKEDIR}/../../../Source/" ABSOLUTE)
get_filename_component(_BOOST_LIBDIR "${_BOOST_CMAKEDIR}/../" ABSOLUTE)

# Create imported target Boost::headers

add_library(Boost::headers INTERFACE IMPORTED)

set_target_properties(Boost::headers PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_BOOST_INCLUDEDIR}"
  INTERFACE_COMPILE_DEFINITIONS "BOOST_ALL_NO_LIB"
)

unset(_BOOST_LIBDIR)
unset(_BOOST_INCLUDEDIR)
unset(_BOOST_CMAKEDIR)

mark_as_advanced(boost_headers_DIR)

[daminetreg]

Just to confirm I deleted the hunter cache and did everything with cmake 3.16.2 on mac catalina and I have the same exact result as above.

I see if I can tweak boost cmake integration to avoid using the Source dir.

[noeffn]

@dan-42 Thanks for picking this up.

@michaeldkroener What toolchain are you using?

Sorry for the late response.
Compiler Clang++9.0 compiling for x86 using BSD
Discovered just now I was on CMake Version 3.15.4
But I tried some previous Versions and had the same issue.
Could still be the CMake version
I did not update the HunterGate for a some time was still on 0.23.214

[dan-42]

@michaeldkroener

I did not update the HunterGate for a some time was still on 0.23.214
I guess you mean 0.23.241 :-)

And you can reproduce it with a minimal test-project?
E.g. that uses Boost just like this:

hunter_add_package(Boost)
find_package(Boost CONFIG REQUIRED)

add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::boost)

like in the boost-uuid example (https://github.com/cpp-pm/hunter/blob/master/examples/Boost-uuid/CMakeLists.txt)

[noeffn]

It turns out if I do just use Boost::boost there is no problem but as soon as I use a component like program_options the problem occurs

CMake File

cmake_minimum_required(VERSION 3.15.0 FATAL_ERROR)

set(CMAKE_MODULE_PATH
	${CMAKE_MODULE_PATH}
	"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
)

include(HunterGate)

HunterGate(
    URL "https://github.com/cpp-pm/hunter/archive/v0.23.241.tar.gz"
    SHA1 "0897935585580d4eece64804f4f48fe9199a7a2c"
)

project(footest LANGUAGES CXX C)

hunter_add_package(Boost COMPONENTS program_options)
find_package(Boost CONFIG REQUIRED program_options)


add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::boost Boost::program_options)

foo.cpp is from
https://github.com/cpp-pm/hunter/blob/master/examples/Boost-uuid/foo.cpp

I get

-- [hunter] Calculating Toolchain-SHA1
-- [hunter] Calculating Config-SHA1
-- [hunter] HUNTER_ROOT: /root/.hunter
-- [hunter] [ Hunter-ID: 0897935 | Toolchain-ID: 0cf3d44 | Config-ID: c83e950 ]
-- [hunter] BOOST_ROOT: /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install (ver.: 1.72.0-p0)
-- [hunter] BOOST_ROOT: /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install (ver.: 1.72.0-p0)
CMake Error at /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install/lib/cmake/Boost-1.72.0/BoostConfig.cmake:120 (find_package):
  Found package configuration file:

    /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install/lib/cmake/boost_program_options-1.72.0/boost_program_options-config.cmake

  but it set boost_program_options_FOUND to FALSE so package
  "boost_program_options" is considered to be NOT FOUND.  Reason given by
  package:

  No suitable build variant has been found.

  The following variants have been tried and rejected:

  * libboost_program_options-mt-d-x32.a (static, default is shared, set
  Boost_USE_STATIC_LIBS=ON to override)

  * libboost_program_options-mt-x32.a (static, default is shared, set
  Boost_USE_STATIC_LIBS=ON to override)

Call Stack (most recent call first):
  /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install/lib/cmake/Boost-1.72.0/BoostConfig.cmake:185 (boost_find_component)
  CMakeLists.txt:19 (find_package)


-- Configuring incomplete, errors occurred!

The same with Boost_USE_STATIC_LIBS=ON results in

-- [hunter] Calculating Toolchain-SHA1
-- [hunter] Calculating Config-SHA1
-- [hunter] HUNTER_ROOT: /root/.hunter
-- [hunter] [ Hunter-ID: 0897935 | Toolchain-ID: 0cf3d44 | Config-ID: c83e950 ]
-- [hunter] BOOST_ROOT: /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install (ver.: 1.72.0-p0)
-- [hunter] BOOST_ROOT: /root/.hunter/_Base/0897935/0cf3d44/c83e950/Install (ver.: 1.72.0-p0)
-- Configuring done
CMake Error in CMakeLists.txt:
  Imported target "Boost::boost" includes non-existent path

    "/root/.hunter/_Base/0897935/0cf3d44/c83e950/Source"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

test@testserver:/home/test/build # cmake --version
cmake version 3.16.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[daminetreg]

I'm a bit concerned by the use of the cmake package config support that was added to Boost in 1.70, the one that @ruslo had done were way better thought for the need hunter has.

Currently the Boost cmake support generates non relocatable files and which search for shared libs by default, while hunter builds static by cmake default.

@ruslo is there a reason why you switched to the boost provided package configs ? We could go back and disable their installation (there is a cli switch for b2 --no-cmake-config), while in parallel trying to upstream the hunter vision of the thing ?

[daminetreg]

So PR #140 should fix that, builds are in progress.

[daminetreg]

Thank you very much.

We may need to up some revisions to ensure it gets rebuilt automatically for users that already had the previous version. Because just changing the schemes files doesn’t account for a new config shasum I believe. Or am I wrong ?

[Bjoe]

Hi @ALL .... I try to reproduced the bug that @michaeldkroener reported #133 (comment) but I didn't get into it. Only if I use Boost::headers
Here is my example: https://github.com/Bjoe/boost-examples/tree/1e81fa941792312f395bf01e68f08ec21ed2dae3
I tried with cmake 3.16.2 and 3.13.4.... no problems ... can some body give me a hint what I did wrong?

Anyway ... what my biggest concern is, I'm not sure if it is the right way to still "remove" the original BoostConfig.cmake from the boost maintainers it self. We should thinking about, when they "change" something, we also must maintain this in BoostConfig in hunter! For example, we are still using Boost::boost for the header libs .... but they introduce in 1.72.0 Boost::headers and add an alias for Boost::boost to be backwards compatible. But I know that they will use Boost::headers "only" in the future and we should use this to be compatible with the "community" :-)

I think the best way is to fix the wrong "path" in boost. Then we can use the config modul from boost and we have lesser to maintain to easier update to newest boost version...

I will try to find the root cause of the "wrong path" and will create a PR in boost ....

[daminetreg]

By the way @Bjoe IMHO it's good to continue supporting boost as always for the moment.

Because

• the typical FindBoost.cmake is still maintained for this version and still works as usual by CMake.
• boost cmake support isn't official yet AFAIK ( Or did I miss it somewhere ? There are no mention in docs or in changelog, so as of boost practice it's private implementation details. )

Transitioning is good only when the fixes are applied in upstream Boost ( and I encourage you applying them ).

I think this early boost support is only to test adoption and they didn't intend to break existing builds by just adding some files (but cmake is really awfully greedy when it comes to filesystem search).

[Bjoe]

@daminetreg Last year on the Meeting C++ conference Deniz Bahadir recommended in his talk to use the Boost config moduls from boost and not any more the FindBoost.cmake maintained from cmake. He gives a reason in his talk.
See talk: Oh No! More Modern CMake - Deniz Bahadir - Meeting C++ 2019 https://youtu.be/y9kSr5enrSk
Talking about Boost at timeline: 34:20
Why you should not use FindBoost.cmake anymore from cmake 36:42
New boost version with cmake config modul: 38:05

The BoostConfig module exists since boost 1.70, so I think they will never ever an "official statement" from the boost community because what I heard and know about boost and cmake there was in the past to many "destructive" discussion about cmake ... that's my assumption.
The cmake "community" knows there exists now a BoostConfig ... there is a hint in FindBoost see https://cmake.org/cmake/help/latest/module/FindBoost.html?highlight=findboost#boost-cmake

So in my opinion, the BoostConfig modul is released in 1.72. so it should be usable :-)

We can quickly fix the issue in hunter ... but maybe it shows us a problem "in hunter" how we build boost in hunter ?

Maybe if we can introduce an easily alias to Boost::header ?

But as soon as possible, we should use BoostConfig from the boost project, I think.

[dan-42]

@Bjoe I honer your position to use what boost provides, but exactly the BoostConfig is the one that causes the problems.
And even if boost provided usable CMake support in the next versions, this will not fix the issue we have here and now for version 1.72.

So for the next boost version we can have a look if the CMake support improved and use the one provided by boost, or we stick to what we have.

But for now we need to have the PR #140 to make it work

[Bjoe]

I quickly tried to understand what is going wrong and my assumption was correct.
The real problem is that hunter build boost libs with the stage and not with the official install target that the boost documentation is recommends (see https://www.boost.org/doc/libs/1_72_0/more/getting_started/unix-variants.html#easy-build-and-install).

I change this in url_sha1_boost_library.cmake.in (see Bjoe@24cd58a), now the paths are correct in the BoostConfig moduls and I used in my "quick" tests only the original boost config and it works ....
So it is not a problem or bug in boost!
I will test this now on travis and then also in my "production" environment on linux, android, iOS and windows.

But this is also not a proper solution, because as the comment said:

install only libraries, headers installed in url_sha1_boost

Now it install the headers twice :-(

But I don't find the boost build process in hunter not that "proper" anyway ... why is hunter for every boost lib create an own "build process" .... I my opinion that can be improved. But this is an other discussion.

[Bjoe]

Btw. I'm not against #140 you should merge this if @rbsheth is fine with that ... at the end I will introduce a cmake flag to choose if you will use the BoostConfig from hunter or the original BoostConfig from boost ....

[Bjoe]

I created a PR to enable via

hunter_config(Boost
    VERSION ${HUNTER_Boost_VERSION}
    CMAKE_ARGS USE_CONFIG_FROM_BOOST=ON
)

original cmake config modul from boost .... #154 needs tester/reviewer, thanks :-)

[rbsheth]

Should be solved by #140