summaryrefslogtreecommitdiff
path: root/expat/README
diff options
context:
space:
mode:
authorTor Lillqvist <tlillqvist@suse.com>2012-11-15 17:55:05 +0200
committerTor Lillqvist <tlillqvist@suse.com>2012-11-15 18:33:09 +0200
commitd8edf07ed9e7a3e2f2ab43ffd2935b93326f2caa (patch)
treefcc91844900827238324f8ad93f1dbf64306b13b /expat/README
parent42782fddff98eeab5c8249918e9ba000f08c22e8 (diff)
Bin use of UTF-16 expat variant in the Windows shell extension
Thus we can drop that variant completely. Change-Id: I11a8e40436921219bd6dd4afad4c7907ccb6b84c
Diffstat (limited to 'expat/README')
-rw-r--r--expat/README36
1 files changed, 0 insertions, 36 deletions
diff --git a/expat/README b/expat/README
index d7ce6824d686..579d3d3d6bd5 100644
--- a/expat/README
+++ b/expat/README
@@ -1,40 +1,4 @@
Simple SAX parser library with added UTF-16 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
-variants, 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/]