Hi all,

I’m adding a package to Conan Center . It builds correctly for macos/clang/x86_64 , but fails for macos/clang/M1-arm64 . The error comes from this piece of code:

cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
add_executable(func-gen "func-gen.cpp")
target_include_directories(func-gen
    PRIVATE "."
    PRIVATE "${CMAKE_CURRENT_BINARY_DIR}"
function(generate_funcs HDR SRC VER)
    get_filename_component(HDR_DIR "${HDR}" PATH)
    file(MAKE_DIRECTORY "${HDR_DIR}")
    get_filename_component(SRC_DIR "${SRC}" PATH)
    file(MAKE_DIRECTORY "${SRC_DIR}")
    add_custom_command(
        COMMAND func-gen "${HDR}" "${SRC}" "${VER}"
        OUTPUT "${HDR}" "${SRC}"
        DEPENDS func-gen
endfunction()
It basically cannot find func-gen during execution (full logs here):
/bin/sh: func-gen: command not found
That generate_funcs function is called from a parent CMakeLists.txt. I’ve tried using a variable:
set(func-gen-path ${CMAKE_CURRENT_BINARY_DIR}/func-gen PARENT_SCOPE)
instead of using the name of the target, func-gen, directly, and that works for linux/gcc (haven’t tried yet for macos/clang/M1-arm64), but breaks something else in my windows build. Apart from the fact that I don’t think it should be the proper way to go.
Any idea why macos/clang/arm64 cannot find the target here?
Thanks!
    add_custom_command(
        COMMAND "$<TARGET_FILE:func-gen>" "${HDR}" "${SRC}" "${VER}"
        OUTPUT "${HDR}" "${SRC}"
        DEPENDS func-gen
Try to use a genex here. I know add_test does some magic for command replacement, but I don’t know if add_custom_command does or not.
 Roberto Turrado Camblor:
Any idea why macos/clang/arm64 cannot find the target here?
I suspect that something is different in PATH.
 Ben Boeckel:
Try to use a genex here. I know add_test does some magic for command replacement, but I don’t know if add_custom_command does or not.
It does. The add_custom_command() docs say this:
If COMMAND specifies an executable target name (created by the add_executable() command), it will automatically be replaced by the location of the executable created at build time if either of the following is true:
The target is not being cross-compiled (i.e. the CMAKE_CROSSCOMPILING variable is not set to true).
New in version 3.6: The target is being cross-compiled and an emulator is provided (i.e. its CROSSCOMPILING_EMULATOR target property is set). In this case, the contents of CROSSCOMPILING_EMULATOR will be prepended to the command before the location of the target executable.
If neither of the above conditions are met, it is assumed that the command name is a program to be found on the PATH at build time.
              
Many thanks @ben.boeckel, that worked. The Conan Center build can find the executables now.
That didn’t make the build work though, but that’s another problem that has nothing to do with CMake anymore.
              
Thanks for the comment @craig.scott. Cross-compilation may be the cause of the issue here.
I don’t fully understand yet how Conan Center is compiling my package for M1-arm64, but if you have a look at the profiles, it seems to say arch_build=x86_64 and then, for profile_host, arch=armv8:
Auto detecting your dev setup to initialize the default profile (/Users/jenkins/w/prod/BuildSingleReference@3/.conan/profiles/default)
Found apple-clang 13.0
apple-clang>=13, using the major as version
Default settings
	os=Macos
	os_build=Macos
	arch=x86_64
	arch_build=x86_64
	compiler=apple-clang
	compiler.version=13
	compiler.libcxx=libc++
	build_type=Release
*** You can change them in /Users/jenkins/w/prod/BuildSingleReference@3/.conan/profiles/default ***
*** Or override with -s compiler='other' -s ...s***
Configuration (profile_host):
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13.0
os=Macos
[options]
libqasm:shared=True
[build_requires]
[env]
[conf]
 Roberto Turrado Camblor:
I don’t fully understand yet how Conan Center is compiling my package for M1-arm64, but if you have a look at the profiles, it seems to say arch_build=x86_64 and then, for profile_host, arch=armv8:
Ah ha! I ran into something like this when supporting our superbuilds over to macOS arm64. Rosetta 2 is likely getting in the way here. The insight is that when a process is running in x86_64 mode under Rosetta, any process it launches will also see x86_64 only and arm64-only binaries will refuse to launch. It would seem that /bin/sh (or something that launches it) is x86_64-only and that is why it fails to launch. I would highly recommend getting multi-arch or arm64-only copies of everything in your setup (ninja was the problem in my case).