but the problem is a lot simplier for macOS as we don't go so far in the past. I have already answered about the memory consumption and for the rest related to libicu this is a fixable detail. And I don't speak about the fact that there is propably an icu implementation in android already. Tickeys - Instant audio feedback for typing. UnMuteMic - macOS app to mute & unmute the input volume of your microphone. Cog - Free and Open Source Audio Player for macOS. If we change the icu version we also need to change the data. Background Music - Background Music, a macOS audio utility: automatically pause your music, set individual apps volumes and record system audio. But the data is in the kiwix-android side and not in the kiwix-lib.aar. We embed icu in kiwixlib and we need to load the icu data at runtime before using it. This should not be different on macOS, but we make it available for Swift.Īnd we have problem on android already. The only jni used is for kiwixlib.so, nothing else (at least for now). Distributing a dynamic library embedding static ones is just being in the middle and we will have problems.Īnd yes, this is the same with android. This is why there is the "war" package everything individually and be sure everything is coherent (linux packaging system) VS bundle everything and run everywhere (appimage.). (rmp, deb, howebrew, appimage, chocolatey, pip, npm. This is why we have so much (concurrent) packaging systems. Yes, software distribution is a nightmare. But we have to answer all those questions before simply drop a libkiwix.so on a server. I don't know how it is on macos/ios side. On android we toke care about compiling libkiwix using the oldest sdk possible to be compatible with the most devices possible, assuming that android doesn't break compatibility between version. If we change the icu version we also need to change the data. What would be the version actually used by the project ? Will it depends of the order of the include directories ? Of the order in which libraries are loaded ? We may have the project compiling with version Y headers and linking with version X.Īnd yes, this is the same with android. What happends if we include xapian version X in kiwix-lib and the project also use xapian Y. I'm not concern about the memory size but about the conflict in version. This is a problem, but not a unsolvable one, and in the worse case we use a bit too much memory, which is an acceptable price to pay here. Regarding your concern about code duplicates.
0 Comments
Leave a Reply. |