supported_archs noarch prevents CMake from setting correct flags

[barracuda156]

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 

[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.

[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.

[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?

[RJVB (René Bertin)]

Replying to barracuda156:

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.

A PortGroup is intended to set up the most generally possible context, such that the largest possible number of ports can exploit it with only minimal tweaking.

If you're talking about the 1.1 version of the CMake PG, it already has a cmake.set_osx_architectures option (checked in a bit of an awkward fashion I see, 3x instead of once). Setting that to no or false should solve your issue.

Another thing that could be considered is if one could make this option automatic to a point, i.e. don't add a -DCMAKE_OSX_ARCHITECTURES=${configure.build_arch} (or the +universal equivalents) if the configure.build_arch is an empty string. But it should probably be tested if that doesn't break anything.

I'm a bit surprised that CMake would NOT handle an empty CMAKE_OSX_ARCHTIECTURES as an implicit "just build for the current architecture". I can't see any scenario where this kind of being a stickler for the rules would have any benefits... and the variable itself just lists the arguments to add to the compiler's -arch flag.

Are we talking principles here or do you have an actual example of a build failing or otherwise not behaving as you would want?