conan-darwin-toolchain
conan-darwin-toolchain copied to clipboard
theodelrieu
Incompatible with Conan contexts
This project works wonderfully for building CMake and autotools projects, when using conan install -pr=profile
However, when working with build_requires and contexts (conan install -pr:h=ios -pr:b=macos), as is suggested in the Conan docs, this package sets the environment incorrectly.
iOS profile:
[settings]
os=iOS
os.version=13.1
os_build=Macos
arch=armv8
arch_build=x86_64
compiler=apple-clang
compiler.version=12.0
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
darwin-toolchain/1.0.8@theodelrieu/stable
[env]
macOS profile:
[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=x86_64
compiler=apple-clang
compiler.version=12.0
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
darwin-toolchain/1.0.8@theodelrieu/stable
[env]
environment during build() with an iOS host profile and a macOS build profile:
CONAN_CMAKE_OSX_ARCHITECTURES x86_64
CONAN_CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
CONAN_CMAKE_SYSTEM_NAME Darwin
CONAN_CMAKE_SYSTEM_PROCESSOR x86_64
CONAN_CMAKE_TOOLCHAIN_FILE /Users/asdf/.conan/data/darwin-toolchain/1.0.8/theodelrieu/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/darwin-toolchain.cmake
Note that fields are populated for a macOS build, even though the host is iOS.
The obvious answer might be to just say don't use contexts, but unfortunately I can't do that breaks some of my dependencies.
Hi @tolstikh,
I'm working on it! See this issue I posted earlier https://github.com/conan-io/conan/issues/8292
This package works with the 2 profile approach: https://conan.io/center/ios-cmake
(maybe its time to update the documentation...? )
this works as build_requires as you have it, @tolstikh , but you only put it into the host (ios) profile, not into the build one
@a4z
Yes, I need to take a look at ios-cmake. At work I have to build my own libc++, so darwin-toolchain doesn't fit this need right now.
Does ios-cmake support autotools et. al? Or only CMake?
Btw I saw you answered to my issue, I'll answer tomorrow ;)
@a4z thanks for the suggestion. I had considered using ios-cmake instead, but it doesn't do anything for autotools (or other build systems). I like that this project is more comprehensive that way.
Perhaps it's worth it to split this package into an iOS and a macOS package?
I have no problems so far with auto tool projects, but I think I only use openssl that uses autotools, and that does a lot of stuff in the recipe.
I made also some adoptions to curl I think.
If you can point me to a project that uses autotools, then we could check if that works and how to do that.
I use the ios-cmake toolchain because it has so much options and not just ios, and so many users so it seems well tested, it seems to be kind of standard (have seen it included in quite some projects).
I think it is not a big problem to copy the package_id function from this package into the recipe of the ios-cmake toolchain, and adopt to the 2 profile way like I did in the android-ndk package .... I will give it a look as soon I have time ( maybe not too soon) , however, if you can tell me any autoconf and other build tool package that is a good testing candiate, please let me know
@a4z merging the best from both projects sounds like a good idea.
I'll do a clean rebuild of my deps soon with just the ios-cmake toolchain, I'll let you know if anything comes up.
if you can name me a package that is suitable for testing, I can start look into it
(sorry for off topic)
@a4z I've actually rebuilt my whole project from scratch with the ios-cmake build requirement on my iOS host profile, and surprisingly everything actually worked. I was expecting some autotools issues to pop up, but it was smooth sailing.
GDAL is a rather complex and modular autotools project with several optional dependencies involving other tools like Meson. If you can crossbuild that I imagine you can crossbuild anything.
