alicevision
[bug] Boost system has been deprecated
Describe the bug Boost system has been removed in boost 1.89
To Reproduce Trying to build in archlinux
Expected behavior Building fine
Screenshots
Log
-- Building in Release configuration
CMake Warning (dev) at CMakeLists.txt:127 (find_package):
Policy CMP0167 is not set: The FindBoost module is removed. Run "cmake
--help-policy CMP0167" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/lib/cmake/Boost-1.89.0/BoostConfig.cmake:141 (find_package):
Could not find a package configuration file provided by "boost_system"
(requested version 1.89.0) with any of the following names:
boost_systemConfig.cmake
boost_system-config.cmake
Add the installation prefix of "boost_system" to CMAKE_PREFIX_PATH or set
"boost_system_DIR" to a directory containing one of the above files. If
"boost_system" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
/usr/lib/cmake/Boost-1.89.0/BoostConfig.cmake:262 (boost_find_component)
/usr/share/cmake/Modules/FindBoost.cmake:609 (find_package)
CMakeLists.txt:127 (find_package)
Desktop (please complete the following and other pertinent information):
- OS: arch linux
- Other dependencies version : boost 1.89
- CCTag version: 1.0.4
Hi, thanks for reporting.
I still see system among the components here https://www.boost.org/libraries/latest/grid/
Maybe you did not install it?
What is actually deprecated is the findBoost module of CMake (Warning in your log) but if you provide where it can find BoostConfig.cmake that should be fine.
Hi, thanks for reporting. I still see
systemamong the components here https://www.boost.org/libraries/latest/grid/ Maybe you did not install it? What is actually deprecated is the findBoost module of CMake (Warning in your log) but if you provide where it can findBoostConfig.cmakethat should be fine.
Hi @simogasp
My goal was to install meshroom on my arch linux system but I'm not sure the packages are often enough maintained to be installed without a bit of hand work...
I forked your repo and I tried to fix the build but then hit an eigen 3 -> 5 problem and noticed that most things on my path to meshroom rely on NVidia hardware... I bought AMD because of the numerous warnings about NVidia linux support... Also my CMake already poor skills have been long forgotten...
So I'm not sure how much effort this is really worth... On my side I have given up for now. I'll check it again in a couple of months I guess...
Thanks for the answer and your efforts for this project !
A similar problem was spotted here if this helps: https://github.com/facebook/folly/issues/2489
Ok I see. Thanks for the heads up, I guess we will have to switch to boost 1.89 and eigen 5 at some point. For boost it's kind of a breaking change as it will be difficult to support both versions
Boost system has been removed in boost 1.89
@fredleb I'm running into this issue as well, but I cannot find an authoritative source on this. Did you spot a related message in the release notes, somehow? Or a specific commit?
@sehe @fredleb Out of curiosity, have you tried to just remove boost::system from the CMake? Does it compile? I suspect that we don't even depend on boost::system, at least not directly. I should better check the code but I think ever since a major refactoring to get rid of boost::stacktrace and other stuff, boost::system may be just a leftover that is no longer needed by the project explicitly (i.e. maybe other boost's components that we use may have a dependency on it, but it's not our job to import it)
Ok I made a quick test on macos (without cuda) it compiles fine without boost::system explicitly declared. @griwodz do you remember if in the cuda part anything related to boost::system was necessary? It does not seem so to me but you know better ;-)
@simogasp It's not /that/ simple though. If you install boost it typically installs all the header files, which is nice because many of the libraries are header-only, including Boost System. It's not that Boost System could ever be deprecated. It's just that maybe they stopped supporting c++03 so they could deprecate the non-header-only parts, obviating the need for any compiled component.
Now here's the kicker: as long as you depend on any boost library that causes the headers to be added on the include path, any code that is header-only (including some uses of non-header-only libraries that do not depend on the compiled library parts) is going to compile.
So, removing Boost::system as an explicit component dependency doesn't guarantee you don't depend on it (in fact, it's one of the most depended on components of Boost). It simply means that you didn't depend on any compiled part for that component.
TL;DR: I'm pretty sure this is what is going on because I know for a decade Boost System is starting to support header-only use more and more. See for example https://www.boost.org/doc/libs/1_89_0/more/getting_started/windows.html#header-only-libraries:
Boost.System is header-only since Boost 1.69. A stub library is still built for compatibility, but linking to it is no longer necessary.
However, I'm very eager to see a documented CHANGE in the Boost documentation or commit history to really know what to do with our build systems.
@sehe Sure, I was talking more from a CMake perspective.
Boost provides targets Boost::xxxx only for the libraries that require linking, e.g. Boost::filesystem etc. If in 1.89 they switch to header-only for system it means that you cannot anymore look for and then link with Boost::sytem.
Say that your project only depends on system. In v1.89, instead of linking to Boost::system, you have to look for boost with
find_package(Boost REQUIRED)
and then simply give the include directory to your project target
target_include_directories(my_project PRIVATE ${Boost_INCLUDE_DIRS})
Now, to your point, if system is an indirect dependency because, say, your project depends on Boost::filesystem which happens to depend on system, the system's headers will be included in your project by the target Boost::filesystem itself, so you don't have to worry about it and include it in the project.
If your project depends on Boost::filesystem AND on system too because you are directly using some headers, then you should do both, use the target Boost::filesystem and target_include_directories. In reality, the second one is not really necessary because they will be included by the target anyway, but it would be a good practice to explicitly include them.
In don't think they have deprecated the system library itself. As you saidm they might have deprecated/removed the compiled library and system is now a header only library,
For CCTag, I think we left the dependency to system by mistake, it is not a direct dependency. So it should be just fine removing it. If any of the other boost libraries that we depend on happens to depend on system, the associated target will bring the necessary include path to compile the system headers.
You can try this https://github.com/alicevision/CCTag/tree/dep/fix_boost to see if it works with 1.89