On Apr 15, 2004, at 11:12 AM, George R wrote:
I went with the --with-data-packaging=archive initially for 3 pragmatic reasons: (1) it seems to take a really, really long time to build them into a library, and (2) once parrot "ships", if we use --with-data-packaging=archive or --with-data-packaging=files then that would permit end users to add/remove encoding without needing access to a compiler, and (3) our automated tests end up linking in our libraries, so building the ICU data as a static library slows this down significantly, since it has to copy around all of the bits for each test.
But (1) and (3) are just short-term, convenient-for-ongoing-development reasons.
Item 1 should improve in ICU 3.0 on most platforms when a shared or static data library is used.
<detail>
Basically, ICU writes out the .dat file to computer assembly, and lets the C compiler create the object code from the assembly. This is similar to how the Windows builds work. It's all data, and there are no instructions in the assembly. It's also much quicker than the original implementation. There are some platforms that can't work with this build speed improvement without some porting help (please contact me if you want to help out). If the new building process can't be done on a platform, it uses the original slow building process (this only happens when we don't have access to the compiler or platform for testing).
</detail>
Item 2 can already be done when a static or shared data library is used (at least the add part). If the ICU_DATA environment variable is set, or u_setDataDirectory() is used, you can add or override the data used within ICU's library. If a user wanted to remove data, the user would need some of ICU's tools to unpackage and repackage the .dat archive, which requires a little detailed knowledge about what all the data and tools are used for. The ICU User's Guide should help in those cases.
I'm not sure what you mean by item 3, but the new 3.0 data build process should hopefully help out.
I have a few (bugs if not patches) to submit. (For instance, with ICU 2.8, building the tools seems to fail in the case of --enable-static --disable-shared, because of the "s" prefix.)
That's done on purpose. The static library names collide with AIX shared library names and Windows import library names. I recommend that you don't use --disable-shared and build both the static and shared libraries. I don't think autoconf allowed us to remove the --disable-shared option. I also doubt that the --disable-shared would work on all platforms anyway because library versioning is done differently (this is due to poor shared library versioning support on some platforms). You can use the static libraries, but the tools kind of require shared libraries. Patches to make ICU work with just static libraries, and with the current naming scheme, will probably be accepted.
I'll be in touch!
:-)
George http://oss.software.ibm.com/icu/
