190ddfcdb2
But... the names our ICU libraries get built as clash exactly with Android's system ICU library names, predictably leading to chaos. I will have to come up with a non-clashing names for our ICU libraries on Android. (But isn't it stupid to include an own build of ICU if there is one in the system already? Sure, but on the other hand the NDK doesn't include ICU headers or libraries, so clearly Google doesn't consider it part of the documented API. No guarantee of version stability etc. Indeed best to avoid them then.) |
||
---|---|---|
.. | ||
prj | ||
createmak.cfg | ||
createmak.pl | ||
icu-mp.patch | ||
icu4c-4_4_2-wchar_t.patch | ||
icu4c-aix.patch | ||
icu4c-android.patch | ||
icu4c-build.patch | ||
icu4c-escapespace.patch | ||
icu4c-rpath.patch | ||
icu4c-strict-c.patch | ||
icu4c-warnings.patch | ||
icu4c.8320.freeserif.crash.patch | ||
icuversion.mk | ||
makefile.mk | ||
Readme |
This file describes the procedure of creating and maintaining makefiles.zip # Obo's part The automatically generated makefiles are not necessarily optimal. The build is started from allinone/all directory, and the all.mak file is used to build the entire module through. Each subtarget in this file is going to be made recursively unless there is a switch RECURSE=0. If the switch is available, for each subtarget all its prerequisites should be made earlier than the subtarget itself. Therefore, you should order the ALL target's prerequisites so that they are going to be built in a consistent order. Unfortunately there's no automatic process for it, just prove the prerequisites for each subtarget and push them forward in target's ALL prerequisites list. The changes between generated & optimized all.mak can be seen when comparing the files from v1.5 & v1.6 of makefiles.zip.