e4050a653b
I don't understand what the "universal" byte order thing tries to say. Sure, Apple's compilers can produce fat binaries, i.e. containing code for multiple architectures, which I guess might have differing byte order. But I think the test for an -arch flag being present here is backwards, surely if you specify -arch i386 for instance, then we *know* that the byte order is little endian, not "universal". Anyway, this broke ICU when built against MacOSX SDK 10.6 at least, the ICU configury used wrong suffix for ICUDATA_NAME, and genbrk failed in i18npool with a mysterious "can not initialize ICU. status = U_FILE_ACCESS_ERROR" message. |
||
|---|---|---|
| .. | ||
| prj | ||
| createmak.cfg | ||
| createmak.pl | ||
| icu-mp.patch | ||
| icu4c-4_4_2-wchar_t.patch | ||
| icu4c-aix.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.