Open avetiso opened 2 years ago
There's probably a way to do in the actual meson.build files
Meson is principled here, and actually refuses to allow projects to encode information modifying the conan cross file properties. This does need to be solved as part of conan's build environment setup.
Meson is principled here, and actually refuses to allow projects to encode information modifying the conan cross file properties.
I am not sure what that means, Meson is agnostic about Conan, it is not that it can refuse to encode information regarding Conan files, it is that it doesn't even know that such files exists.
If the thing is that adding to [properties]
custom things is necessary, I think that is an easy feature. The MesonToolchain
already has support for [project_options]
, it would be identical. Someone wants to contribute it?
I can try to tackle this sometime this weekend, in the meantime simply layering an additional cross file with these properties works.
I am not sure what that means, Meson is agnostic about Conan, it is not that it can refuse to encode information regarding Conan files, it is that it doesn't even know that such files exists.
It means that conan provides a Meson cross file, and Meson doesn't permit setting values of Meson cross files from meson.build
files because Meson strictly separates build recipes (meson.build
) from environment setup (cross files).
If the thing is that adding to
[properties]
custom things is necessary, I think that is an easy feature.
That is indeed what is necessary, and hopefully should be quite easy.
The OP theorized that as a workaround for not being able to add custom things to [properties]
, it might be possible to define custom properties by modifying meson.build
-- I clarified that that isn't so. :)
It means that conan provides a Meson cross file, and Meson doesn't permit setting values of Meson cross files from meson.build files because Meson strictly separates build recipes (meson.build) from environment setup (cross files).
Yes, now I see what you mean. Conan does exactly the same, recipe conanfile.py
cannot define values of settings, it is decoupled and those values can only be defined in profiles files (or cli args). It is important to separate the definition from the configuration.
That is indeed what is necessary, and hopefully should be quite easy.
@avetiso might try it this weekend, if not possible, we will see if we can do it ourselves.
@memsharded @eli-schwartz could use some input here.
Added some code to the meson toolchain to add [properties] to the generated conan_meson_cross.ini file. Works as expected.
First draft of the important part looks like this:
if arch_host != arch_build:
self.properties["needs_exe_wrapper"] = True
elif (os_host == "iOS" and os_build != "iOS") or (os_host == "Android" and os_build != "Android"):
self.properties["needs_exe_wrapper"] = True
I know nobody compiles on iOS to run on iOS, but I'd imagine there are situations where this is done on Android? Idk, could use some input on what you guys want to support here in terms of checks.
However, it seems to behave differently than if I were to simply layer a meson cross file from the conanfile.py via builds_args.
When I pass the cross file via conan to meson.configure(), everything builds okay. (the cross file in this case is just a [properties] sections with needs_exe_wrapper=true).
When I try to build iOS x86_64 with sdk_root as iphonesimulator, I get this:
dyld[60350]: DYLD_ROOT_PATH not set for simulator program
meson.build:1:0: ERROR: Executables created by cpp compiler c++ are not runnable.
When I try to build iOS armv8 with sdk_root as iphoneos, I get this:
meson.build:1:0: ERROR: Executables created by cpp compiler c++ are not runnable.
In both cases, the generated conan_meson_cross.ini file contains
[properties]
needs_exe_wrapper=true
but meson is still trying to run them. Is there some sort of auto detection for iOS simulator at work here? I never specified an exe wrapper.
My expected behavior was that meson would not try to run either executable for iOS.
EDIT: I've also tried replacing needs_exe_wrapper with skip_sanity_check and run into the same issue.
You're getting an error message from a code branch that explicitly runs only if the compiler is not a cross compiler, or an exe_wrapper is set.
The precise debug contents of builddir/meson-logs/meson-log.txt
might prove instructive in deducing the cause.
Hmm, in my conan profile I set the correct tools.apple:sdk_path for iOS depending on whether it's x86_64 (simulator) or armv8 (native for iOS). I was under the impression that simply doing that would handle the rest, but it sounds like I'll also need to set CC and CXX explicitly to the compilers in those SDKs. I'll try that later.
Actually, here are the flags in the conan_meson_cross.ini:
c_link_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64']
cpp_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64'] + preprocessor_definitions
cpp_link_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64']
pkg_config_path = '/Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7'
AFAIK, the compiler used to cross compiler iOS is the same as the compiler used to compile natively on macOS. The flags that it's generating are correct, and even the comment in the code you linked me seems to agree. So I am using a cross compiler, and I didn't set an exe wrapper as far as I am aware.
We've been compiling it like this for a while, actually, using Cmake. In conan our iOS profiles always just used compiler=apple-clang that's provided by macOS.
I know nobody compiles on iOS to run on iOS, but I'd imagine there are situations where this is done on Android? Idk, could use some input on what you guys want to support here in terms of checks.
I think it is safe to assume that building for iOS is always cross-building.
If you have already some conan changes, feel free to share a diff, or even better, a PR. You can put it in "draft" mode if it is not final. Our CI is doing some tests already that are cross-building to iOS, so not an issue to test that too.
@memsharded thanks, I might get an MR up but preferably after I figure this issue out with meson first.
@eli-schwartz here is the meson-log.txt:
Build started at 2022-03-21T09:21:32.707626
Main binary: /opt/homebrew/opt/python@3.9/bin/python3.9
Build Options: -Dprefix=/Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/package/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7 -Dlibdir=lib -Dbindir=bin -Dsbindir=bin -Dlibexecdir=bin -Dincludedir=include -Ddefault_library=shared -Dbackend=ninja -Dbuildtype=release
Python system: Darwin
The Meson build system
Version: 0.61.2
Source dir: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7
Build dir: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build
Build type: native build
Project name: base64
Project version: 0.0.0
Sanity testing C++ compiler: c++
Is cross compiler: False.
Sanity check compiler command line: c++ sanitycheckcpp.cc -o sanitycheckcpp.exe -m64 -O3 -mios-simulator-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.4.sdk -arch x86_64 -stdlib=libc++ -DNDEBUG
Sanity check compile stdout:
-----
Sanity check compile stderr:
-----
Running test binary command: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build/meson-private/sanitycheckcpp.exe
meson.build:1:0: ERROR: Executables created by cpp compiler c++ are not runnable.
Here is me running the compile command successfully as meson generated it, and checking the arch and format:
➜ meson-private ls
meson.lock sanitycheckcpp.cc sanitycheckcpp.exe
➜ meson-private rm sanitycheckcpp.exe
➜ meson-private c++ sanitycheckcpp.cc -o sanitycheckcpp.exe -m64 -O3 -mios-simulator-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.4.sdk -arch x86_64 -stdlib=libc++ -DNDEBUG
➜ meson-private file sanitycheckcpp.exe
sanitycheckcpp.exe: Mach-O 64-bit executable x86_64
➜ meson-private
Here is the conan_meson_cross.ini that was generated:
[properties]
needs_exe_wrapper = true
[constants]
preprocessor_definitions = []
[project options]
[binaries]
c = 'clang'
cpp = 'clang++'
[built-in options]
buildtype = 'release'
b_ndebug = 'true'
backend = 'ninja'
c_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64'] + preprocessor_definitions
c_link_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64']
cpp_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64'] + preprocessor_definitions
cpp_link_args = ['-mios-simulator-version-min=11.0', '-isysroot', '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk', '-arch', 'x86_64']
pkg_config_path = '/Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7'
[build_machine]
system = 'darwin'
cpu_family = 'aarch64'
cpu = 'armv8'
endian = 'little'
[host_machine]
system = 'darwin'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'
Again, I was expecting that it would not try to run the sanity check executable. But the command is definitely cross compiling successfully from what I can tell, and the compiler being invoked is a cross-compiler, although meson is reporting it as if it wasn't in the logs...
Here is the log file when I apply the layered cross-file, notice that it reports it as a cross build instead of a native build now, and the compile command has a -c
at the very end:
Build started at 2022-03-21T09:33:32.482125
Main binary: /opt/homebrew/opt/python@3.9/bin/python3.9
Build Options: -Dprefix=/Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/package/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7 -Dlibdir=lib -Dbindir=bin -Dsbindir=bin -Dlibexecdir=bin -Dincludedir=include -Ddefault_library=shared -Dbackend=ninja -Dbuildtype=release '--cross-file sanity_check_off.ini'
Python system: Darwin
The Meson build system
Version: 0.61.2
Source dir: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7
Build dir: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build
Build type: cross build
Project name: base64
Project version: 0.0.0
Sanity testing C++ compiler: c++
Is cross compiler: True.
Sanity check compiler command line: c++ sanitycheckcpp.cc -o sanitycheckcpp_cross.exe -m64 -O3 -mios-simulator-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.4.sdk -arch x86_64 -stdlib=libc++ -DNDEBUG -c
Sanity check compile stdout:
-----
Sanity check compile stderr:
-----
C++ compiler for the host machine: c++ (clang 13.1.6 "Apple clang version 13.1.6 (clang-1316.0.21.2)")
C++ linker for the host machine: c++ ld64 762
Sanity testing C++ compiler: c++
Is cross compiler: False.
Sanity check compiler command line: c++ sanitycheckcpp.cc -o sanitycheckcpp.exe
Sanity check compile stdout:
-----
Sanity check compile stderr:
-----
Running test binary command: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build/meson-private/sanitycheckcpp.exe
C++ compiler for the build machine: c++ (clang 13.1.6 "Apple clang version 13.1.6 (clang-1316.0.21.2)")
C++ linker for the build machine: c++ ld64 762
Build machine cpu family: aarch64
Build machine cpu: arm64
Host machine cpu family: aarch64
Host machine cpu: arm64
Target machine cpu family: aarch64
Target machine cpu: arm64
Adding test "all"
Build targets in project: 2
base64 0.0.0
User defined options
Cross files : sanity_check_off.ini
backend : ninja
bindir : bin
buildtype : release
default_library: shared
includedir : include
libdir : lib
libexecdir : bin
prefix : /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/package/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7
sbindir : bin
Found ninja-1.10.2 at /opt/homebrew/bin/ninja
Running compile:
Working directory: /var/folders/2f/dsvntyz16wsc3jtzbtfwz4n80000gq/T/tmp950qp0u7
Command line: c++ /var/folders/2f/dsvntyz16wsc3jtzbtfwz4n80000gq/T/tmp950qp0u7/testfile.cpp -o /var/folders/2f/dsvntyz16wsc3jtzbtfwz4n80000gq/T/tmp950qp0u7/output.obj -c -std=c++17
Code:
int i = static_cast<int>(0);
Compiler stdout:
Compiler stderr:
Compiler accepts -std=c++17: YES
Running compile:
Working directory: /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build/meson-private/tmp7d8aqpwg
Command line: c++ /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build/meson-private/tmp7d8aqpwg/testfile.cpp -o /Users/dario.avetisov/.conan/data/base64/0.0.0/mx/stable/build/dca4ecc8d11e9a9e0c04f5eec36874503c0bdec7/build/meson-private/tmp7d8aqpwg/output.obj -c -m64 -O3 -mios-simulator-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.4.sdk -arch x86_64 -stdlib=libc++ -DNDEBUG -O0 -fpermissive -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument --print-search-dirs
Code:
Compiler stdout:
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6
Compiler stderr:
Okay, I think I had an assumption here. I assumed that the generated conan_meson_cross.ini file was automatically configured for consumption by meson but that doesn't appear to be the case.
Passing it manually the same way I did the layed sanity_check_off.ini file I had seems to have the same effect.
Is that the intended behavior?
Okay, I think I had an assumption here. I assumed that the generated conan_meson_cross.ini file was automatically configured for consumption by meson but that doesn't appear to be the case.
Meson doesn't get it automatically, it has to be passed in the command line as an argument, is that what you mean?
Yes, that's what I mean. Just one of those assumptions that only hits you way down the road that you shouldn't have assumed that.
It does seem to work fine now, PR should be up by tonight hopefully. :)
I had been going to say, that the Build Options part of the logfile you posted didn't mention anything about a cross file being specified on the command line. :)
There is a well known case in meson that it will fail to correctly auto detect if the build machine can execute host binaries if the build machine is Macos and the host is iOS because in my case the arch is arm64 in both. The result is that the build fails because Meson trys to execute the binary as part of of its 'compiler sanity check'. This fails of course, and stops the build, even though it was actually successful.
The suggested fix from Meson is to set
in conan_meson_cross.ini. However, there doesn't seem to be any way to add [properties] to this field from the Meson Toolchain. There's probably a way to do in the actual meson.build files, but I'd imagine for people trying to use conan for cross-platform, it would be useful to be able to set this at the profile level, or at the very least from the ConanFile via the Meson Toolchain.
Any thoughts on this?