cmake: Subproject does not use native-compilation for targets

[lhearachel]

Describe the bug
When building a cross-compilation C/C++ project, CMake subprojects do not seem to respect native compilation rules, instead preferring cross-compilation.

To Reproduce
For any necessary context, our full project is here.

I added the following lines to ./meson.build, near the top of the file:

cmake = import('cmake')

And created the following file armips.wrap in our subprojects directory:

[wrap-git]
url = https://github.com/Kingcom/armips.git
revision = master
depth = 1
directory = armips

When loading this subproject using the cmake module and attempting to pull in the armips-bin target (which should build the executable tool), Meson fails during project configuration:

| CMake Error at CMakeLists.txt:2 (project):
| The CMAKE_CXX_COMPILER:

| mwccarm

| is not a full path and was not found in the PATH.

| Tell CMake where to find the compiler by setting either the environment
| variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
| to the compiler, or to the compiler name if it is in the PATH.

I inspected the generated CMakeMesonToolchainFile.cmake, and it indeed is loading the settings from our cross-compile configuration. I modified the native-compile configuration to include cmake module settings, but these were not picked up:

[cmake]

CMAKE_C_COMPILER   = 'gcc'
CMAKE_CXX_COMPILER = 'g++'

The cmake target functions, to my knowledge, do not permit setting native: true like Meson targets. I tried to override these with subproject options, but that didn't seem to work, either:

cmake_opts = cmake.subproject_options()
cmake_opts.set_override_option('native', 'true')
armips_subproj = cmake.subproject('armips', options: cmake_opts)
armips_exe = armips_subproj.target('armips-bin')

Expected behavior
Meson should build the CMake subproject using native-compile configuration rather than cross-compile.

system parameters

• Is this a cross build or just a plain native build (for the same computer)? cross build (native subproject)
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) WSL 2 - Debian 12 (bookworm)
• what Python version are you using e.g. 3.8.0 3.11.7
• what meson --version 1.2.1
• what ninja --version if it's a Ninja build 1.11.1

[dcbaker]

This is sort of a known issue because Meson assumes all subprojects (regardless of how they're being built) are for the host machine.

I have some patches (now in need of a rebase): #12258 that fix this by allowing a subproject to be built for either the host or build machine, including CMake subprojects. The goal is that you would just say subproject('foo', native : true) and Meson would set the rest up automatically using the cross file configuration.

[lhearachel]

Aha! It looks like one of my colleagues on our project has been following along with this. I guess he figured out that we would need this before I did. 😁 He has been on hiatus for a few months now; is there anything that I can do to help out with getting those patches test and built?

We have a workaround at the moment, but it involves either:

1. dumping the source code of an entire tool into the repository (not ideal)
2. forking the dependency and setting up meson for it (though I'm not sure that this would even work, based on what you mentioned)

[dragonmux]

We've wound up hitting this bug in Black Magic Debug when a user tried building the firmware (cross-compiled) and associated host program which depends on HIDAPI. Please see the attached log.

For the time being we're going to fully port HIDAPI to Meson, doing away with the subproject stub they have, to resolve this. This is not particularly maintainable though.

xobs-meson-log.txt