summaryrefslogtreecommitdiff
path: root/expat
diff options
context:
space:
mode:
authorTor Lillqvist <tlillqvist@suse.com>2012-10-03 16:17:34 +0300
committerTor Lillqvist <tlillqvist@suse.com>2012-10-03 16:20:04 +0300
commita29217cc273de1faad8c3522bc23a11d650addbf (patch)
treed05c5946eb1195c444833e535de8d32509397c40 /expat
parentda7f5e0e946e4bad87da06754709ac29eea9ab81 (diff)
More information
Change-Id: I9f9a85cbe74dfb22a2dff67e8a0b7dd4eca6ebf6
Diffstat (limited to 'expat')
-rw-r--r--expat/README36
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/]