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