Minimal proof of concept of universal binaries support for CMakeToolchain #15775
Conversation
conans/test/functional/toolchains/cmake/test_universal_binaries.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
This looks great!
While we have got requests to support something like this, one detail that is often neglected is that this may not work at all . That is, if the build scripts have logic that is conditional on the target architecture (whether this is CMake, autotools, etc), it may not be possible to generate a universal binary in the same pass, or worse, it may generate one but one of the two is missing some crucial options. By this I mean any logic that is contingent on, say, whether CMAKE_CROSSCOMPILING is enabled, or having logic around CMAKE_SYSTEM_PROCESSOR - etc.
So while it "may be possible" for a binary to exist with arch=x86_64-armv8 - it may be that it is impossible to generate it in a single pass, and may require generating the files "independently" for each architecture and them "fusing" them together. Which makes me wonder if we should consider a way of creating a multi-arch package from two previous existing single-arch packages. Food for thought :D
conans/test/functional/toolchains/cmake/test_universal_binaries.py
Outdated
Show resolved
Hide resolved
I think this idea has potential, I'd probably try to prioritize this, as it would be a way more general solution, valid for any build system, not adding extra complexity on the recipe+build-system side. It sounds a bit complex with the current model but with some ideas and building blocks, like what it is done in |
Yes, absolutely true, this will not work in some cases. For those cases maybe we should use something similar to this: conan-io/conan-extensions#116 |
…conan into basic-universal-binaries-support
Changelog: Feature: Add basic support in CMakeToolchain for universal binaries.
Docs: conan-io/docs#3642