Hi Roger, Thanks again for your feedback. Most useful.
In this particular case, our application is only reading/writing our own internal configuration files, so no user input as such. So I should be good not having to transcode. All the characters in our files are UTF-8 only. Thanks for patching the wchar_t change so quickly! I'll give it a try (hopefully sometime later this week). I certainly understand the current naming convention for the library and agree that it is currently correct. The problem I have is with our own application. I've been tasked with converting our application (actually a suite of desktop and web applications) to 64 bit. Our application is a mix of C++, C#, Java and COBOL (yes, it's that old) and the latest version of Java (soon to be released 18.3) is ditching 32-bit support, forcing a move to 64-bit. We have a lot of JNI and C++ code that is used in our Java web applications and this code will all need to be converted. However, we don't have time to convert the entire suite and so we will be left with 32-bit components that will eventually be replaced with 64-bit web equivalents over time. So, for a period of time, our applications will be a mix of 32 and 64-bit components. Some of those components will have to exist in both 32 and 64-bit versions are they are shared between the new web apps and the older 32-bit desktop apps. Some of these shared components use Xerces C++ and I will therefore require both 32 and 64-bit builds. Unfortunately, we will be forced to have these components *in the same folder*. Again, this is a short-term issue which will eventually be solved by moving to a different installer. So it's all a bit of a mess that will eventually be resolved once we web enable everything and are purely 64-bit only. TL;DR : We need both 32 and 64-bit versions of Xerces C++ to exist in the same folder at runtime. I know this is probably a unique case, so implementing something just for this might be too much effort. I can always hand-craft the VS project files to generate the names I need, so not a big issue. As a side note, we have a lot of 32-bit C++ code that needs conversion, but this is going to take time (other 3rd party libraries involved). If you were to drop 32-bit support, this could become an issue for us in the short-term. I'm not sure if there are other Xerces C++ users who have legacy 32-bit code that they need to maintain. Please don't drop 32-bit support too soon! Kind regards, Mark -----Original Message----- From: Roger Leigh [mailto:rle...@codelibre.net] Sent: 23 January 2018 22:46 To: c-users@xerces.apache.org Subject: Re: How to build with XMLCh = wchar_t on Windows platform. On 23/01/18 14:59, Mark Douglas wrote: > Hi Roger, > > I think Microsoft have had wchar_t as a type way before char16_t was > introduced (as far back as I can remember, which is getting shorter as I get > older :)). At the time, Microsoft were well known for doing things the > 'Microsoft way' and not following standards very well. So maybe they backed > themselves into a corner to some extent. > > Indeed, your suggested edit has worked! I now have XERCES_XMLCH_T > defined as wchar_t :) That's great to hear. > I'm not quite sure why I'd need a transcoder if I'm using wchar_t across the > board, so hopefully I can get away with having to worry about it. The only > XML files we consume are UTF-8, so everything *should* just work. Fingers > crossed. For the most part, it's unlikely to be used unless you have some non-UTF-8 input. Not sure if it's used for UTF-8/UTF-16 conversions. If you would like to give it a try, https://issues.apache.org/jira/browse/XERCESC-2132 now has a patch attached, or you can download directly from the linked github branch. Just add "-Dxmlch-type=wchar_t" when running CMake. > I'm going to push my luck a bit here and ask an unrelated question. I need to > build both 32 and 64 bit binaries for our application (it's a long story), > but the Xerces C++ CMake system generates .LIBs and .DLLs with the same name. > Is it possible to specify that one or other of the builds generates different > output filenames? For example, I'd like to generate a xerces-c_3_2x64.dll for > my 64-bit build. At the moment I'm having to hand-craft the generated VS > project file to achieve this. It's certainly possible to configure CMake to add architecture-specific suffixes. However, there would be a good bit of breakage resulting from that--the DLL naming pattern is used by e.g. autoconf, CMake FindXercesC and other scripts to find the library, and this would cease to work. And there are likely many other users of the library who depend on the stability of the existing names. As a result, I'd think keeping the existing scheme as the default would be necessary. But, it should certainly be possible to add an option to add a suffix to the library names for custom builds of the library. For example "-Dlibrary-suffix=my-suffix" or "-Dlibrary-suffix=TRUE" (for automatic addition of architecture). Do you have any established convention for the names of the suffixes? My team's strategy, which matches how things are typically done on Unix and with CMake, is to have a separate build directory for 32-bit builds and 64-bit builds so that the names never clash even when they are identical. The libraries are unprefixed across the board, and 32-bit and 64-bit binaries are never mixed. Likely we'll be dropping 32-bit builds at some point though; not sure anyone actually uses them... Regards, Roger
