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