Re: Integrating CMake support for xerces

2017-06-23 Thread Vitaly Prapirny
Vitaly Prapirny wrote on 22/06/2017 10:53: Roger Leigh wrote on 21/06/2017 17:40: That line (PlatformUtils.cpp:27) is #if HAVE_CONFIG_H #include #endif so it either can't cope with "#if xxx" (which is used in many places), or the error is in the generated "config.h". I'm afraid you'll

Re: Integrating CMake support for xerces

2017-06-22 Thread Vitaly Prapirny
Roger Leigh wrote on 21/06/2017 17:40: That line (PlatformUtils.cpp:27) is #if HAVE_CONFIG_H #include #endif so it either can't cope with "#if xxx" (which is used in many places), or the error is in the generated "config.h". I'm afraid you'll need to identify the cause of the error

Re: Integrating CMake support for xerces

2017-06-21 Thread Roger Leigh
On 21/06/17 14:53, Vitaly Prapirny wrote: Roger Leigh wrote on 21/06/2017 13:58: Sorry, too hasty. Please try this revised patch which actually works. CMake worked without error, but compilation failed just the same way as in my previous message. That line (PlatformUtils.cpp:27) is #if

Re: Integrating CMake support for xerces

2017-06-21 Thread Vitaly Prapirny
Roger Leigh wrote on 21/06/2017 13:58: Sorry, too hasty. Please try this revised patch which actually works. CMake worked without error, but compilation failed just the same way as in my previous message. Good luck! Vitaly

Re: Integrating CMake support for xerces

2017-06-21 Thread Roger Leigh
On 21/06/17 11:17, Roger Leigh wrote: On 21/06/17 10:46, Vitaly Prapirny wrote: Roger Leigh wrote on 21/06/2017 12:20: On 21/06/17 08:48, Vitaly Prapirny wrote: I've got an error while running cmake with "Borland Makefiles" generator and Borland C++ Builder 5 compiler. Is BCB5 still

Re: Integrating CMake support for xerces

2017-06-21 Thread Vitaly Prapirny
Roger Leigh wrote on 21/06/2017 13:17: Thanks. This was a problem with the int type check fallbacks. Please see the attached patch or this github branch: https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback This was a search-replace error when porting m4/xerces_int_types, and

Re: Integrating CMake support for xerces

2017-06-21 Thread Roger Leigh
On 21/06/17 10:46, Vitaly Prapirny wrote: Roger Leigh wrote on 21/06/2017 12:20: On 21/06/17 08:48, Vitaly Prapirny wrote: I've got an error while running cmake with "Borland Makefiles" generator and Borland C++ Builder 5 compiler. Is BCB5 still supported? It's not a combination I've

Re: Integrating CMake support for xerces

2017-06-21 Thread Vitaly Prapirny
Roger Leigh wrote on 21/06/2017 12:20: On 21/06/17 08:48, Vitaly Prapirny wrote: I've got an error while running cmake with "Borland Makefiles" generator and Borland C++ Builder 5 compiler. Is BCB5 still supported? It's not a combination I've personally tested, but I can't see any evidence

Re: Integrating CMake support for xerces

2017-06-21 Thread Roger Leigh
On 21/06/17 08:48, Vitaly Prapirny wrote: Roger Leigh wrote on 21/06/2017 09:54: On 21/06/17 02:42, Cantor, Scott wrote: Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds. I

Re: Integrating CMake support for xerces

2017-06-21 Thread Vitaly Prapirny
Roger Leigh wrote on 21/06/2017 09:54: On 21/06/17 02:42, Cantor, Scott wrote: Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds. I don't want to leave them on trunk if

Re: Integrating CMake support for xerces

2017-06-21 Thread Roger Leigh
On 21/06/17 02:42, Cantor, Scott wrote: Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds. I don't want to leave them on trunk if they're going to atrophy and I don't really

Re: Integrating CMake support for xerces

2017-06-20 Thread Cantor, Scott
Roger, Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds. I don't want to leave them on trunk if they're going to atrophy and I don't really imagine we'd be doing anything to

Re: Integrating CMake support for xerces

2017-06-12 Thread Boris Kolpackov
Roger Leigh writes: > If we every wanted to drop the Autotools to only have one system to > maintain, this would provide compatibility with a traditional > configure/make/make install workflow. I'm not suggesting doing this at this > point in time, just wanted to mention

Re: Integrating CMake support for xerces

2017-06-11 Thread Roger Leigh
On 16/05/17 20:02, Cantor, Scott wrote: I'm not entirely sure about the question you're asking here. By autoconf-compatible build files, you're talking about the end result of configure--the generated Makefiles and headers, or the intermediate autoconf/make scripts like configure/Makefile.in?

Re: Integrating CMake support for xerces

2017-06-03 Thread Cantor, Scott
On 6/3/17, 6:02 PM, "Roger Leigh" wrote: > I guess there's now always the option of deleting some or all of the > stuff under projects/Win32 if you wanted to avoid updating the version > in them all! Oh, I intended to remove all that. My project's going to be moving up

Re: Integrating CMake support for xerces

2017-06-03 Thread Roger Leigh
On 31/05/17 14:23, Cantor, Scott wrote: Roger, if you want to check the patch into trunk that's fine. I'm holding off bumping the versions to 3.2 since it will break your current patch and it would be best if I figure out how to get the version bumped in the new Windows builds anyway. I

Re: Integrating CMake support for xerces

2017-05-31 Thread Cantor, Scott
Roger, if you want to check the patch into trunk that's fine. I'm holding off bumping the versions to 3.2 since it will break your current patch and it would be best if I figure out how to get the version bumped in the new Windows builds anyway. -- Scott

Re: Integrating CMake support for xerces

2017-05-18 Thread rleigh
On 2017-05-17 17:30, Cantor, Scott wrote: On 5/17/17, 12:21 PM, "rle...@codelibre.net" wrote: I spoke too soon; it's not working for the VS generators on Windows when using multiple configurations. I'll fix this up tomorrow. FWIW, the names currently are the same

Re: Integrating CMake support for xerces

2017-05-17 Thread Cantor, Scott
On 5/17/17, 12:21 PM, "rle...@codelibre.net" wrote: > I spoke too soon; it's not working for the VS generators on Windows when > using multiple configurations. I'll fix this up tomorrow. FWIW, the names currently are the same for 32 and 64 builds. That probably is as

Re: Integrating CMake support for xerces

2017-05-17 Thread rleigh
On 2017-05-17 16:35, rle...@codelibre.net wrote: On 2017-05-17 16:26, Cantor, Scott wrote: On 5/17/17, 11:11 AM, "rle...@codelibre.net" wrote: I've attached a followup patch, also on my cmake-trunk github branch, which does this. With this patch applied, you should

Re: Integrating CMake support for xerces

2017-05-17 Thread rleigh
On 2017-05-17 16:26, Cantor, Scott wrote: On 5/17/17, 11:11 AM, "rle...@codelibre.net" wrote: I've attached a followup patch, also on my cmake-trunk github branch, which does this. With this patch applied, you should get identical versioning to Autoconf and Visual

Re: Integrating CMake support for xerces

2017-05-17 Thread Cantor, Scott
On 5/17/17, 11:11 AM, "rle...@codelibre.net" wrote: > I've attached a followup patch, also on my cmake-trunk github branch, > which does this. With this patch applied, you should get identical > versioning to Autoconf and Visual Studio. Great, I'm WfH today but I'll see

RE: Integrating CMake support for xerces

2017-05-17 Thread rleigh
On 2017-05-16 21:47, Cantor, Scott wrote: OK. I'll look into copying the existing Windows and Libtool semantics exactly. If there's a possibility for aligning them with the next major release, we could revisit it then, but I'll revert to the status quo for now. Thx. I hope that

RE: Integrating CMake support for xerces

2017-05-16 Thread Cantor, Scott
> Definitely not; this is the most complex conversion I've done to date. > The previous most complex one was libtiff, which also had a fair amount > of historical stuff. Most are trivial in comparison. Good to know. > Hopefully I got the question you were asking. I didn't do this in the >

Re: Integrating CMake support for xerces

2017-05-16 Thread Roger Leigh
On 16/05/2017 19:42, Roger Leigh wrote: configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp @ONLY) I should have mentioned: from an autoconf point of view,

Re: Integrating CMake support for xerces

2017-05-16 Thread Roger Leigh
On 16/05/2017 19:02, Cantor, Scott wrote: There's certainly a good amount of duplication, most of it intentionally so that the CMake logic mirrors the existing Autoconf feature tests exactly. Right, I understand the motivation. And Xerces has one of the more horrendous config.h messes I've

RE: Integrating CMake support for xerces

2017-05-16 Thread Cantor, Scott
> There's certainly a good amount of duplication, most of it intentionally > so that the CMake logic mirrors the existing Autoconf feature tests > exactly. Right, I understand the motivation. And Xerces has one of the more horrendous config.h messes I've dealt with, it wouldn't necessarily be so

Re: Integrating CMake support for xerces

2017-05-16 Thread Roger Leigh
On 16/05/2017 16:37, Cantor, Scott wrote: Additionally, if anyone wanted to review and test the patch, it's attached to the above ticket and also available here: https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 Playing with this now, I had two issues I wanted to ask about. One is

RE: Integrating CMake support for xerces

2017-05-16 Thread Cantor, Scott
One issue I did notice on the Windows side is that the DLL names are different from the existing convention. I would have to personally adjust them back and I don't think we'd have any reason to want them changed, so I assume that could be adjusted back? -- Scott

RE: Integrating CMake support for xerces

2017-05-16 Thread Cantor, Scott
> Secondly, I'm mainly playing with the Windows side of this, and I was unclear > if it's possible to generate solution files for both 32- and 64-bit at once? > It > looks like it picks one to do at a time so that if you had to build both you'd > have to generate the whole set of files twice in

RE: Integrating CMake support for xerces

2017-05-16 Thread Cantor, Scott
> Additionally, if anyone wanted to review and test the patch, it's > attached to the above ticket and also available here: > https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 Playing with this now, I had two issues I wanted to ask about. One is that it looks like there definitely is a

RE: Integrating CMake support for xerces

2017-04-26 Thread Dean Roddey
26, 2017 4:04 AM To: c-dev@xerces.apache.org Subject: Re: Integrating CMake support for xerces On 26/04/2017 01:30, Cantor, Scott wrote: > On 4/25/17, 3:17 PM, "Roger Leigh" <rle...@codelibre.net> wrote: >> That said, I'd not be averse to including support for stand

Re: Integrating CMake support for xerces

2017-04-26 Thread Cantor, Scott
On 4/26/17, 4:04 AM, "Roger Leigh" wrote: > Agreed that just moving up to C++98 standard types in and of itself > would be greatly beneficial. There should be no portability barrier to > achieving that. No, definitely not. I've been using the STL and Boost for years now

Re: Integrating CMake support for xerces

2017-04-26 Thread Roger Leigh
On 26/04/2017 01:30, Cantor, Scott wrote: On 4/25/17, 3:17 PM, "Roger Leigh" wrote: That said, I'd not be averse to including support for standard C++; using Xerces is often a bugbear due to its age. All our code is now C++11, with RAII wrappers to make Xerces play

Re: Integrating CMake support for xerces

2017-04-25 Thread Cantor, Scott
On 4/25/17, 8:30 PM, "Cantor, Scott" wrote: > So far there is very little divergence, just a few small API additions that > are unique to the trunk. So I don't foresee anything > terribly risky about releasing this after some additional fixes, some > testing, and

Re: Integrating CMake support for xerces

2017-04-25 Thread Cantor, Scott
On 4/25/17, 3:17 PM, "Roger Leigh" wrote: > Switching to git would be wonderful. We could also enable CI testing > with e.g. Travis or some other CI service on github at that time to > enable testing of all PRs, if that would be accceptable. Or does the > Apache

Re: Integrating CMake support for xerces

2017-04-25 Thread Roger Leigh
On 25/04/2017 18:56, Cantor, Scott wrote: Since we are sharing plans, we (as in Code Synthesis) are planning to package Xerces-C++ for build2[1] in the near future (but no definite time-frame). While I haven't looked into this closely yet, the options we consider range between just packaging it

RE: Integrating CMake support for xerces

2017-04-25 Thread Cantor, Scott
> Since we are sharing plans, we (as in Code Synthesis) are planning > to package Xerces-C++ for build2[1] in the near future (but no > definite time-frame). While I haven't looked into this closely > yet, the options we consider range between just packaging it as > is to pretty much forking it.

Re: Integrating CMake support for xerces

2017-04-23 Thread Roger Leigh
On 23/04/2017 18:26, Cantor, Scott wrote: On 4/22/17, 2:59 PM, "Roger Leigh" wrote: There are two choices for merging it: - to the 3.1 branch - to the trunk, for releasing as 3.2 Or a third branch, but I think you already did that via git anyway and that's simpler in

Re: Integrating CMake support for xerces

2017-04-23 Thread Cantor, Scott
On 4/22/17, 2:59 PM, "Roger Leigh" wrote: > There are two choices for merging it: > - to the 3.1 branch > - to the trunk, for releasing as 3.2 Or a third branch, but I think you already did that via git anyway and that's simpler in practice so we can dismiss that one. >