> 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
> 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 be
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
-
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 tha
> 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
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 dea
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,
"configure_fil
> 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
> patch
