When releasing libzim and libkiwix, we use config native_mixed with is a
mix of static and dynamic linking:
- Dependencies are build as static libraries.
- Released projects (libzim/libkiwix) are build as dynamic libraries,
statically linked to dependencies.
This way, we have only one `.so` file which contain all our needed symbols.
However, this logic is "local" to each project.
This mean that libkiwix is linked **statically** to libzim.
So libkiwix.so is containing libzim symbols.
But on "java-libkiwix", we are both linking to libzim.so and libkiwix.so.
If the version of the (dynamically) used libzim.so is not the same that the
version on which we have (statically) linked libkiwix.so, we end with
symbols of two different versions being loaded and conflicting.
So let's rebuild libkiwix with last version of libzim to avoid this conflict.
This reverts commit 05fc3b409c.
This was a temporary commit to make the PR compile with a dev branch of libzim.
Now PR on libzim is merged. We must remove this commit.
- Archive already existing must not stop download of other archives.
- Use copytree instead of rename to use second archive as patch on existing
directory. (No need to remove tmpdir, as it is a temporary directory)
Job `Trigger_Docker` is run in a simple environment not configured.
So tools as `ninja` are not installed. But we don't care as we just want
to trigger a docker build.
But `common` script now start by asking kiwix-build the build dir.
kiwix-build must not fail in this case.
The target_platform option has always be wrongly named.
This is not the platform we are targeted but how we compile.
This was ok at beginning as specifying how we compile somehow define
for what we compile but this is not a one to one mapping.
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
We compile only libzim on bionic, for compatibility with old libc.
No need to compile all other dependencies (and fight with some of them not
compiling)
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).
When running command without `shell=True`, python's subproccess will look
for variable `"PATH"` and `b"PATH"` and will complain if both are set.
So the defaultdict should not return something for `b"PATH"`.
We also escape space ` ` in the environment variables to not break
everything with directory containing space.
no_skip is thus computed automatically depending on project being our or not.
We dont want to skip configure on our own projetcs (limited impact, simplifies deps mgmt)
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
When we use `--disable-tools` (ie, when we are cross-compiling), ICU
will build the data only if it detects we are cross-compiling.
This make sens until we cross-compiling for wasm.
Wasm output is a script file with the interpreter in the sdk we have
installed. So ICU's configure can run the test binary and so doesn't detect
we are cross-compiling.
So we have to patch ICU Makefile to make it build the ICU data anyway.
ICU is used to:
- List locales (`locales_tree`)
- Get information about those locales in different languages (`lang_tree`)
- Remove accents (`translit`)
Tracing ICU without custom data, we also load `likelySubtags` and
`metadata`. Not sure why and what happen when missing but let's be
conservatives and include them.
We don't have a version 13.0.0 for libkiwix.
So the master branch of libkiwix is generating version 12.1.1.
We must use the correct version as we try to fix the rpath on macos
and we we don't have the right version, we fail because the lib file
doesn't exist.
This is mainly a release of libkiwix 12.1.0 as 12.1.0 introduce breaking
changes.
No need to rebuild kiwix-tools (it is already builded with 12.1.0)
Don't build kiwix-destkop as current version of kiwix-desktop is not
ported to kiwix-13.0.0 (`main` is, but not last release).
Matthieu Gautier
Emmanuel Engelhart
renaud gaudin