Opened 9 months ago

Last modified 9 months ago

#69317 new defect

supported_archs noarch prevents CMake from setting correct flags

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.9.1
Keywords: Cc: jmroot (Joshua Root), ryandesign (Ryan Carsten Schmidt), mascguy (Christopher Nielsen)
Port: cmake, cmake-devel

Description

A port may not install arch-specific files, but it may build such (typically tests). Building requires correct arch flags to be passed. However it appears that supported_archs noarch (which is assigned on a basis of installed objects) forces -DCMAKE_OSX_ARCHITECTURES="", and arch flags vanish. This is wrong. The only reason why it is not obvious is that buildbots build for a native arch, which works. There are multiple scenarios where arch flags are required though.

As an example, this is what I get with CLI11:

--->  Configuring CLI11
Executing:  cd "/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_CLI11/CLI11/work/build" && /opt/local/bin/cmake -G "CodeBlocks - Unix Makefiles" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_INSTALL_PREFIX="/opt/local" -DCMAKE_INSTALL_NAME_DIR="/opt/local/lib" -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_C_COMPILER="$CC" -DCMAKE_CXX_COMPILER="$CXX" -DCMAKE_OBJC_COMPILER="$CC" -DCMAKE_OBJCXX_COMPILER="$CXX" -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_POLICY_DEFAULT_CMP0060=NEW -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_MODULE_PATH="/opt/local/share/cmake/Modules" -DCMAKE_PREFIX_PATH="/opt/local/share/cmake/Modules" -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH="/opt/local/lib" -Wno-dev -DCLI11_BUILD_TESTS=ON -DCLI11_BUILD_EXAMPLES=OFF -DCMAKE_OSX_ARCHITECTURES="" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" -DCMAKE_OSX_SYSROOT="/" /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_CLI11/CLI11/work/CLI11-2.4.1 

Change History (3)

comment:1 Changed 9 months ago by jmroot (Joshua Root)

You're free to set configure.build_arch to $build_arch (or any other value you like) if the default isn't suitable in your "multiple scenarios" that involve not building for a native arch. It might be fine for the cmake portgroups to not add -DCMAKE_OSX_ARCHITECTURES to configure.args at all in the noarch case, but I don't really know.

Last edited 9 months ago by jmroot (Joshua Root) (previous) (diff)

comment:2 Changed 9 months ago by jmroot (Joshua Root)

If the concern is that your tests have external dependencies that need to have matching archs, then your port is by definition not noarch. If you can turn off the building of the tests, you could have a tests variant that makes the port not declare itself noarch.

comment:3 in reply to:  1 Changed 9 months ago by barracuda156

Replying to jmroot:

You're free to set configure.build_arch to $build_arch (or any other value you like) if the default isn't suitable in your "multiple scenarios" that involve not building for a native arch.

Apparently it will not work correctly already when trying to build for i386 on x86_64 or universal composed of these two. (So I did not mean something necessarily as exotic as building for ppc on x86.)

And yeah, there are obviously ways to get around that, but arguably it is just incorrect behavior that should rather be fixed with CMake PG than hacked around. It is understandable why it makes sense to mark the installed port as noarch, it is not clear why flags should be discarded during the build. If nothing arch-specific gets installed, then flags make no difference in this regard and can be retained, so that tests are not broken. If flags do make a difference, then it is not a noarch port.

Or do I miss something about noarch?

Note: See TracTickets for help on using tickets.