From a29217cc273de1faad8c3522bc23a11d650addbf Mon Sep 17 00:00:00 2001 From: Tor Lillqvist Date: Wed, 3 Oct 2012 16:17:34 +0300 Subject: More information Change-Id: I9f9a85cbe74dfb22a2dff67e8a0b7dd4eca6ebf6 --- expat/README | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'expat') 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/] -- cgit