Opened 3 years ago
Closed 18 months ago
#64757 closed request (invalid)
How to enable Cmake to find Boost?
Reported by: | barracuda156 | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | powerpc | Cc: | |
Port: | cmake |
Description
I am trying to make a new port and it requires Boost. Outside of Macports I just use this, and it works: -DBoost_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include
.
However doing the same in a local port file fails:
CMake Error at /opt/local/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find Boost (missing: system filesystem program_options date_time) (found version "1.76.0") Call Stack (most recent call first): /opt/local/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /opt/local/share/cmake-3.22/Modules/FindBoost.cmake:2375 (find_package_handle_standard_args) CMakeLists.txt:207 (find_package)
I started with:
configure.args-append -DBOOST_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include
That failed to change anything, and ended with the following, which had zero effect again (flags are passed, but to no effect):
configure.env-append BOOST_ROOT=/opt/local/libexec/boost/1.76 \ BOOST_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include configure.args-append -DBOOST_ROOT=/opt/local/libexec/boost/1.76 \ -DBOOST_INCLUDE_DIR=/opt/local/libexec/boost/1.76/include \ -DBOOST_LIB_DIR=/opt/local/libexec/boost/1.76/include
Change History (6)
comment:1 follow-ups: 2 3 Changed 3 years ago by reneeotten (Renee Otten)
comment:2 Changed 3 years ago by barracuda156
Replying to reneeotten:
Are you using the
boost
PortGroup already, if not I would to that first as there is some code in there already to setup things correctly.
Great, thank you and @kencu, that indeed helped.
comment:3 follow-up: 4 Changed 3 years ago by barracuda156
Replying to reneeotten:
Are you using the
boost
PortGroup already, if not I would to that first as there is some code in there already to setup things correctly.
As an odd effect on 10.5.8, while I specifically have boost176
in port file (and boost176
is already built even), when I try install my port, Macports insists on installing boost171
instead.
This did not occur on 10.6 PPC, where boost176
was used, as supposed.
comment:4 follow-up: 5 Changed 3 years ago by reneeotten (Renee Otten)
Replying to barracuda156:
Replying to reneeotten:
Are you using the
boost
PortGroup already, if not I would to that first as there is some code in there already to setup things correctly.As an odd effect on 10.5.8, while I specifically have
boost176
in port file (andboost176
is already built even), when I try install my port, Macports insists on installingboost171
instead.This did not occur on 10.6 PPC, where
boost176
was used, as supposed.
not all that surprising if you take a look at the code in the boost
PG:
proc boost::default_version {} { global os.platform os.major # Pin version on Darwin9 and older to pre-c++11 version (1.71) if { ${os.platform} eq "darwin" && ${os.major} <= 9 } { return 1.71 } else { return 1.76 } }
comment:5 follow-up: 6 Changed 18 months ago by mascguy (Christopher Nielsen)
Owner: | set to mascguy |
---|---|
Status: | new → assigned |
Replying to reneeotten:
Replying to barracuda156:
As an odd effect on 10.5.8, while I specifically have
boost176
in port file (andboost176
is already built even), when I try install my port, Macports insists on installingboost171
instead.This did not occur on 10.6 PPC, where
boost176
was used, as supposed.not all that surprising if you take a look at the code in the
boost
PG:proc boost::default_version {} { global os.platform os.major # Pin version on Darwin9 and older to pre-c++11 version (1.71) if { ${os.platform} eq "darwin" && ${os.major} <= 9 } { return 1.71 } else { return 1.76 } }
While the behavior makes sense in-general, we should also expose an option for the fallback version. That way ports can override it, if they really want/need to.
I'm thinking boost.fallback_version
, which would default to the present value (1.71).
comment:6 Changed 18 months ago by mascguy (Christopher Nielsen)
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Replying to mascguy:
While the behavior makes sense in-general, we should also expose an option for the fallback version. That way ports can override it, if they really want/need to.
I'm thinking
boost.fallback_version
, which would default to the present value (1.71).
Actually, the existing behavior of pg boost
shouldn't require any changes: The fallback version is only set once, when the pg is included. But that's overridden if the port specifies boost.version
.
Net-Net, specify boost.version 1.76
(or whatever version you want), and you're set.
Also, you don't need to specify boost176
in your list of dependencies, as the pg will add that automatically.
Are you using the
boost
PortGroup already, if not I would to that first as there is some code in there already to setup things correctly.