diff options
author | Tor Lillqvist <tlillqvist@suse.com> | 2012-10-03 16:17:34 +0300 |
---|---|---|
committer | Tor Lillqvist <tlillqvist@suse.com> | 2012-10-03 16:20:04 +0300 |
commit | a29217cc273de1faad8c3522bc23a11d650addbf (patch) | |
tree | d05c5946eb1195c444833e535de8d32509397c40 /expat/README | |
parent | da7f5e0e946e4bad87da06754709ac29eea9ab81 (diff) |
More information
Change-Id: I9f9a85cbe74dfb22a2dff67e8a0b7dd4eca6ebf6
Diffstat (limited to 'expat/README')
-rw-r--r-- | expat/README | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/expat/README b/expat/README index 9d39ccf0d927..a3f8399c4da3 100644 --- a/expat/README +++ b/expat/README @@ -1,4 +1,40 @@ Simple SAX parser library with added UCS2 support. +When we build expat internally ("bundled"), we build two variants: One +that has an "ASCII" (actually UTF-8) API, another that has a "Unicode" +(meaning UTF-16) API. Additionally, expat is split into two parts, +expat_xmlparse and expat_xmltok. It's the former which has the two +variabts, ascii_expat_xmlparse (UTF-8) and expat_xmlparse (UTF-16). + +Code that uses expat then declares in its .mk file which one it wants +to use. See the magic in ../RepositoryExternal.mk, where in the +expat_utf16 case -DXML_UNICODE is passed when compiling source code +that wants to use the UTF-16 variant. + +Now, this sounds fairly clear so far. + +But wait. LO can also be conigured to use a *system* expat +library. The System expat library is only available as one variant, +the "ASCII" one. (But the library is still called just "libexpat", no +"ascii" in the name, that is just LO/OO's convention.) So how does +this work then, how can the code that wants to use the UTF-16 expat +API then actually use the "ASCII" (UTF-8) expat API? Well, in the +SYSTEM_EXPAT case no -DXML_UNICODE is used, so the code needs to check +that and adapt. So in the system libexpat case, mentioning expat_utf16 +in a .mk file doesn't mean any UTF-16-using libexpat would actually be +used. + +Yeah, this is silly, confusing, etc. + +Furthermore, at least Debian actually *does* have also a "Unicode" +expat library, called libexpatw. Debian's LO does not use that, +though. (Using it would require modifications to the LO build +machinery.) + +Now, if LO manages just fine with just the UTF-8 (or, "ASCII") system +libexpat in builds where that is used, why is a separate Unicode one +needed when an internal expat is used? Good question. Next +question. Patches welcome. + From: [http://expat.sourceforge.net/] |