When we introduced CoreKiwix.xcframework, we made two mistakes:
- We forgot that some devs are on Apple Silicon and did not include arm64 arch for simulator
- We kept the `x86_64-apple-ios` target thinking simulator is a “just” an iOS on x64
This target mistake prevented XCode from finding our lib usable with the Simulator on x64.
Not including an arm64 version obviously prevented Silicon-using devs from using the Simulator.
The included libs changes now from
| Name | Content |
| ---------------------------- | ----------------------------------------------------- |
| `ios-arm64` | All iOS devices are arm64 |
| `ios-x86_64-simulator` | Single x64 binary for Simulator |
| `macos-arm64_x86_64` | Fat binary for macOS with both x64 and arm64 |
To
| Name | Content |
| ---------------------------- | ----------------------------------------------------- |
| `ios-arm64` | All iOS devices are arm64 |
| `ios-arm64_x86_64-simulator` | Fsat binary for iOS Simulator with both x64 and arm64 |
| `macos-arm64_x86_64` | Fat binary for macOS with both x64 and arm64 |
- `iOSx64` Platforn renamed to `iOSx64Simulator` with its target fixed to `x86-apple-ios-simulator` (was `x86_64-apple-ios`)
- Added platformn `iOSArm64Simulator` for Apple Silicon devs to run Simulator
- `AppleXCFramework` dependency gets two changes:
- Depends on all those platforms
- `_make_macos_fat()` turned generic and called both for macOS fat binary and iOS Simulator one
It mainly allow to run command in directory containing space.
(Hello, `C:\Program Files\...`)
It would also allow to work on directory containning spaces
(`C:\Users\John Doe`) but xapian configure (at least) expressly doesn't
support it :/
- Run the command without shell=True
- The command must be a list instead of a string.
- All options must also be a list (or an iterable).
CoreKiwix.xcframework is the packaging format required by Kiwix apple (macOS/iOS) reader for libkiwix.
Naming will hopefully be revisited later (libkiwix.xcframework?)
This folder is a combination of all static archive (*.a): dependencies and libkiwix itself
for all apple-supported platforms: macOS x86_64, macOS arm64, iOS arm64 and iOS x86_64.
It also includes the headers.
Note: while iOS archs are separated in the framework, the macOS archs are bundled as a fat binary.
This thus adds:
- A new `apple_all_static` target that lists mentioned sub-platforms.
- A new `AppleXCFramework` virtual dependency and builder
- requires `libkiwix`
- merges the archives into one per target
- creates the fat binary for macOS
- creates the xcframework
- `libkiwix_xcframework-VERSION.tar.gz` because platformname is xcframework
- it only contains the xcframework but in libkiwix_xcframework-VERSION/lib folder
Because with this virtual target, there are no other files
- requires a new `xcframework` platform_name in builddef
- subplatforms deps and macOS/iOS _ok files to make_deps_archive
---
https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle
Until now, mixed targets was only about native build and so we were not
using a meson cross_config file and env var was enough.
But now we also to correctly set it in the cross_config file.
We need to set the property `needs_exe_wrapper` to true for
x86_64 cross compilation.
Else, meson will try to detect if we could run the cross
compiled executable, and because it is the same arch, it will
assume we can. So it will try to sanity check and execute the
cross compiled binary. Then fails.
Instead of having the run_command function setting the
env from the buildEnv, this is the dependency that create the
env and then pass it to the run_command function.
This way, each dependency will be able to set a specific env.
This is needed for win32 on fedora.
It is better to use a specific pkg-config than setting a PKG_CONFIG_LIBDIR.
This avoid other CI (libzim/...) to set a env var specific to win32 build.
- Dependency are installed "striped".
- Our project are build "debugoptimized" by default and "release" when
building release instead of "debug"
We need to update the `base_deps_meta_version` as we are changing how
dependencies are compiled.
This is the big change !!!!
Instead of handling target as primary object and prepare/build targets,
we are handling build steps.
A build step may be a source (preparation) or a build (of the source).
Actualy, a step is a tuple (context, Builder or Source).
The context define the context of the step. It can be :
- 'source', for a Source step
- 'neutral' or the name of a platform for Build step.
Target becomes a "Class only" class.
Sometime the root_path is dependent of the target platform and sometime
not. But sometime dependent of the build arch :/
[TODO] We should move the cross_file generation to the PlatformInfo class.
Introduce also a "NeutralEnv", a build environment independent of the
targeted platform. All `Source` now build using the neutralEnv.
Most of toolchains are also using neutralEnv except android_ndk who is
specific to a platform.
As toolchain are neutral, platform specific environment variables are now
set by the platformInfo directly instead of the toolchain.
renaud gaudin
Matthieu Gautier
ChrisLi