Re: Integrating CMake support for xerces

[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 need to identify the cause of the error here.  Can you include 
config.h in a single test file like this:


#if HAVE_CONFIG_H
#include 
#endif

int main()
{}

with or without the #if/endif?  If you can pinpoint where the problem 
is, we can look at further fixes.
Compilation of that single test file failed with just the same error 
"Expression syntax" when HAVE_CONFIG_H defined without value 
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or 
defined with value (-DHAVE_CONFIG_H=1)


Roger,

After you fix that, I've got another error:

[ 80%] Linking CXX shared library xerces-c.dll
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Error E2194: Could not find file '@CMakeFiles\xerces-c.dir\objects1.rsp'

Good luck!
   Vitaly


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 here.  Can you include config.h in 
a single test file like this:


#if HAVE_CONFIG_H
#include 
#endif

int main()
{}

with or without the #if/endif?  If you can pinpoint where the problem 
is, we can look at further fixes.
Compilation of that single test file failed with just the same error 
"Expression syntax" when HAVE_CONFIG_H defined without value 
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or defined 
with value (-DHAVE_CONFIG_H=1)


Good luck!
   Vitaly

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 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 here.  Can you include config.h in a 
single test file like this:


#if HAVE_CONFIG_H
#   include 
#endif

int main()
{}

with or without the #if/endif?  If you can pinpoint where the problem 
is, we can look at further fixes.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 supported?


It's not a combination I've personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


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


Sorry, too hasty.  Please try this revised patch which actually works.


Roger
>From 294248062d2f2843895c1a62599ebbef4f4e0985 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 21 Jun 2017 11:12:17 +0100
Subject: [PATCH] cmake: XercesIntTypes: Correct signed types and variable
 names

---
 cmake/XercesIntTypes.cmake | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 3390febf7..c840b0010 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/cmake/XercesIntTypes.cmake
@@ -70,13 +70,13 @@ else()
 endif()
 
 # Check type sizes
-check_type_size("short"  SIZEOF_SHORT)
+check_type_size("signed short"   SIZEOF_SHORT)
 check_type_size("unsigned short" SIZEOF_UNSIGNED_SHORT)
-check_type_size("int"SIZEOF_INT)
+check_type_size("signed int" SIZEOF_INT)
 check_type_size("unsigned int"   SIZEOF_UNSIGNED_INT)
-check_type_size("long"   SIZEOF_LONG)
+check_type_size("signed long"SIZEOF_LONG)
 check_type_size("unsigned long"  SIZEOF_UNSIGNED_LONG)
-check_type_size("long long"  SIZEOF_LONG_LONG)
+check_type_size("signed long long"   SIZEOF_LONG_LONG)
 check_type_size("unsigned long long" SIZEOF_UNSIGNED_LONG_LONG)
 check_type_size("__int64"SIZEOF___INT64)
 check_type_size("unsigned __int64"   SIZEOF_UNSIGNED__INT64)
@@ -100,7 +100,7 @@ if(HAVE_CSTDINT OR HAVE_STDINT_H OR HAVE_INTTYPES_H)
   set(XERCES_U64BIT_INT "uint64_t")
 else()
   # Fallback to basic language types
-  if(SIZEOF_SIGNED_SHORT EQUAL 2)
+  if(SIZEOF_SHORT EQUAL 2)
 set(XERCES_S16BIT_INT "signed short")
   elseif(SIZEOF_INT EQUAL 2)
 set(XERCES_S16BIT_INT "int")
@@ -116,9 +116,9 @@ else()
 message(FATAL_ERROR "Couldn't find an unsigned 16-bit type")
   endif()
 
-  if(SIZEOF_SIGNED_INT EQUAL 4)
+  if(SIZEOF_INT EQUAL 4)
 set(XERCES_S32BIT_INT "signed int")
-  elseif(SIZEOF_SIGNED_LONG EQUAL 4)
+  elseif(SIZEOF_LONG EQUAL 4)
 set(XERCES_S32BIT_INT "signed long")
   else()
 message(FATAL_ERROR "Couldn't find a signed 32-bit type")
@@ -133,11 +133,11 @@ else()
   endif()
 
   if(SIZEOF_INT EQUAL 8)
-set(XERCES_S64BIT_INT "int")
+set(XERCES_S64BIT_INT "signed int")
   elseif(SIZEOF_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long")
+set(XERCES_S64BIT_INT "signed long")
   elseif(SIZEOF_LONG_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long long")
+set(XERCES_S64BIT_INT "signed long long")
   elseif(SIZEOF___INT64 EQUAL 8)
 set(XERCES_S64BIT_INT "__int64")
   else()
-- 
2.13.1



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 
all the systems I've tested on all had stdint.h or cstdint, so I 
didn't notice this wasn't working.  I've switched all the types to be 
unambiguously signed, and added SIGNED_ to all the variable names 
where missing.


If you could give that a go, I'd be very interested if this works for 
you, or if you hit any other problems after this point.
CMake worked without error in that branch, but compilation failed (make 
log attached).


Good luck!
   Vitaly

MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
Scanning dependencies of target xerces-c
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
[  0%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Base64.cpp:
[  0%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinFileInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinFileInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinMemInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinMemInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BitSet.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BitSet.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/DefaultPanicHandler.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\DefaultPanicHandler.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/EncodingValidator.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\EncodingValidator.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/HeaderDummy.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HeaderDummy.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/HexBin.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HexBin.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/KVStringPair.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\KVStringPair.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/Mutexes.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Mutexes.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/PanicHandler.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PanicHandler.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/PlatformUtils.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp:
Error E2188 
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp 27: 
Expression syntax
*** 1 errors in Compile ***

** error 1 ** deleting 
src\CMakeFiles\xerces-c.dir\xercesc\util\PlatformUtils.cpp.obj

** error 1 ** deleting src\CMakeFiles\xerces-c.dir\all

** error 1 ** deleting all


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


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 
all the systems I've tested on all had stdint.h or cstdint, so I didn't 
notice this wasn't working.  I've switched all the types to be 
unambiguously signed, and added SIGNED_ to all the variable names where 
missing.


If you could give that a go, I'd be very interested if this works for 
you, or if you hit any other problems after this point.



Regards,
Roger
>From c56f25ebf6f40a68a3232d1132bb7f4953185218 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 21 Jun 2017 11:12:17 +0100
Subject: [PATCH] cmake: XercesIntType: Correct signed types and variable names

---
 cmake/XercesIntTypes.cmake | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 3390febf7..dd5ab472c 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/cmake/XercesIntTypes.cmake
@@ -70,13 +70,13 @@ else()
 endif()
 
 # Check type sizes
-check_type_size("short"  SIZEOF_SHORT)
+check_type_size("signed short"   SIZEOF_SIGNED_SHORT)
 check_type_size("unsigned short" SIZEOF_UNSIGNED_SHORT)
-check_type_size("int"SIZEOF_INT)
+check_type_size("signed int" SIZEOF_SIGNED_INT)
 check_type_size("unsigned int"   SIZEOF_UNSIGNED_INT)
-check_type_size("long"   SIZEOF_LONG)
+check_type_size("signed long"SIZEOF_SIGNED_LONG)
 check_type_size("unsigned long"  SIZEOF_UNSIGNED_LONG)
-check_type_size("long long"  SIZEOF_LONG_LONG)
+check_type_size("signed long long"   SIZEOF_SIGNED_LONG_LONG)
 check_type_size("unsigned long long" SIZEOF_UNSIGNED_LONG_LONG)
 check_type_size("__int64"SIZEOF___INT64)
 check_type_size("unsigned __int64"   SIZEOF_UNSIGNED__INT64)
@@ -102,7 +102,7 @@ else()
   # Fallback to basic language types
   if(SIZEOF_SIGNED_SHORT EQUAL 2)
 set(XERCES_S16BIT_INT "signed short")
-  elseif(SIZEOF_INT EQUAL 2)
+  elseif(SIZEOF_SIGNED_INT EQUAL 2)
 set(XERCES_S16BIT_INT "int")
   else()
 message(FATAL_ERROR "Couldn't find a signed 16-bit type")
@@ -132,12 +132,12 @@ else()
 message(FATAL_ERROR "Couldn't find an unsigned 32-bit type")
   endif()
 
-  if(SIZEOF_INT EQUAL 8)
-set(XERCES_S64BIT_INT "int")
-  elseif(SIZEOF_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long")
-  elseif(SIZEOF_LONG_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long long")
+  if(SIZEOF_SIGNED_INT EQUAL 8)
+set(XERCES_S64BIT_INT "signed int")
+  elseif(SIZEOF_SIGNED_LONG EQUAL 8)
+set(XERCES_S64BIT_INT "signed long")
+  elseif(SIZEOF_SIGNED_LONG_LONG EQUAL 8)
+set(XERCES_S64BIT_INT "signed long long")
   elseif(SIZEOF___INT64 EQUAL 8)
 set(XERCES_S64BIT_INT "__int64")
   else()
-- 
2.13.1



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


Good luck!
   Vitaly

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 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 ensure they worked if 
the solution files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.
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 that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 they're going to atrophy and I 
don't really imagine we'd be doing anything to ensure they worked if 
the solution files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.
I've got an error while running cmake with "Borland Makefiles" generator 
and Borland C++ Builder 5 compiler. Is BCB5 still supported?


Good luck!
   Vitaly


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 imagine we'd be doing anything to ensure they worked if the solution 
files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 ensure they worked if the solution 
files came from cmake now.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 the existence of this solution as a
> possibility for the future.

It would still require CMake to be installed, right? One of the main
advantages of autotools is all you need is a compiler (and make),
everything else is included.

I think if we drop autotools, then we drop them good, without hitching
ourselves to some half-solutions with questionable long-term prospects.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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?


No, the intermediates. People *want*, virtually *demand* the ability to do source builds 
with configure/make/make install and any violation of the norm is just painful for 
anybody using Xerces in their projects together with dozens of other libraries all 
expecting to be built that way. "Different" is bad in this context.


I came across this today, so thought I'd mention it:

  https://github.com/nemequ/configure-cmake

This is a "configure" shell script you drop into a CMake-using project 
to wrap the invocation of cmake with an Autoconf-like shell script, 
which maps all the standard configure options to the cmake equivalents.


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 the existence of this 
solution as a possibility for the future.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 to VC2017 
anyway.

-- Scott

Re: Integrating CMake support for xerces

[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 have now committed the CMake patch as revision 1797546.

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!



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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

[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 for 32 and 64 builds. That
probably is as much because of the timing of them being added, but it
does also relate to the cross-platform point you had, people on
Windows doing dual arch builds don't tend to use different names for
the files (at least not that I've seen) since they tend to just copy
their old makefiles and projects to 64-bit.


The issue was more related to the debug/release DLL names in the .rc 
file than 32/64-bit names.  I've fixed this detail up, and updated the 
patch is in JIRA.  It should now work across to board.


https://issues.apache.org/jira/secure/attachment/12868727/0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch


Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 much because of the timing of them being added, but it does also relate to 
the cross-platform point you had, people on Windows doing dual arch builds 
don't tend to use different names for the files (at least not that I've seen) 
since they tend to just copy their old makefiles and projects to 64-bit.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 get identical
versioning to Autoconf and Visual Studio.


Great, I'm WfH today but I'll see what it does on OS X today and
re-test Windows tomorrow at the office.

Maybe we could look at doing the svn merge next week?


That sounds great.  I'm in the process of re-running all the 256 CI
builds again; no failures so far.


I spoke too soon; it's not working for the VS generators on Windows when 
using multiple configurations.  I'll fix this up tomorrow.



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 Studio.


Great, I'm WfH today but I'll see what it does on OS X today and
re-test Windows tomorrow at the office.

Maybe we could look at doing the svn merge next week?


That sounds great.  I'm in the process of re-running all the 256 CI 
builds again; no failures so far.



Regards,
Roger


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 what it does on OS X today and re-test 
Windows tomorrow at the office.

Maybe we could look at doing the svn merge next week?

-- Scott

RE: Integrating CMake support for xerces

[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 explains things, but I'm happy to go into more detail for
any aspects which are unclear.


Thanks, I'll review further while you make the filename adjustments
but I think if others don't have concerns we can plan for merging it
back to trunk.


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.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Integrating CMake support for xerces

[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
> patch because the intention was not to replace the Autotools.  But I can
> look into this if desired.

Not at the moment, I was just trying to understand the relationship between the 
tools and the implications of having both on the maintenance.

> 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 explains things, but I'm happy to go into more detail for
> any aspects which are unclear.

Thanks, I'll review further while you make the filename adjustments but I think 
if others don't have concerns we can plan for merging it back to trunk.

-- Scott

Re: Integrating CMake support for xerces

[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, 
"configure_file" is directly equivalent to "AC_OUTPUT" but with a bit 
more flexibility in that the input and output names are explicit and can 
differ--no implicit .in extension in the source tree or requirement that 
they have the same pathname.



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 dealt with, it wouldn't necessarily be so much work in 
every project.


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.



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?


No, the intermediates. People *want*, virtually *demand* the ability to do source builds 
with configure/make/make install and any violation of the norm is just painful for 
anybody using Xerces in their projects together with dozens of other libraries all 
expecting to be built that way. "Different" is bad in this context.


Ah, OK.  In the case where we wanted to drop the Autotools and maintain 
just one system, it would be absolutely possible to create a wrapper 
"configure" script which forwards all the expected arguments to cmake. 
Certainly for all prefixes, flags, --with/--enable options etc. 
Likewise with any target name differences--we can create proxy targets 
to forward to the real target.  The only problem might be more esoteric 
cases, like cross-compilation, where it wouldn't be trivial to wrap.  We 
could certainly cater for the common case scenarios though.


Hopefully I got the question you were asking.  I didn't do this in the 
patch because the intention was not to replace the Autotools.  But I can 
look into this if desired.



I think it's fairly simple to change; I'll have to check.  The same also
applies to the full .so version on Unix, which isn't identical to
libtool in its pattern.  Same name to link with, and same SOVERSION
symlink, but the library itself has a slightly different pattern.


I'm not a fan of the non-soname versioning used, but there's backstory there 
and I don't think we want to re-litigate it, so the convention there has been 
to embed the ABI version in the name (libxerces-c-3.1.so, new one will be 
libxerces-c-3.2.so)


OK


The question I have here is this: why is the link name different on
Windows?  With CMake being cross-platform, it would allow the naming and
versioning conventions to be the same on both Unix and Windows.  This is
a usability gain when a cross-platform downstream project wants to link
with xerces: right now they have to hardcode the discrepancy.  I'm sure
we can tweak it to retain the existing platform-specific conventions
with a few additional bits of configuration, however.


Most projects don't have any cross platform build tooling for Linux and 
Windows, so the name difference doesn't really come up much. On the Windows 
side, it's critical for the ABI version tag and a D (for debug) be present, but 
I'm not personally wedded to anything in particular other than, again, not 
wanting to engage in a bikeshedding discussion about it, so leaving it 
consistent with 3.1 seemed the simplest choice.

If there's value in aligning with the Linux names, though, I'm not really 
opposed personally, but Linux doesn't have the debug/non-debug distinction 
either, so I don't think they could really be identical anyway...


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.



I've successfully built various combinations of the Windows build and I get the 
gist of it.

I guess for myself, my comfort level would go up a bit if there was just a 
brief sort of outline of how a given AC_DEFINE or Windows #define would be 
added to the cmake build if it became needed. If I had some comfort level with 
how it works, the duplication wouldn't bother me too much.


This is pretty straightforward:

src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in is the template. 
It's the same as src/xercesc/util/Xerces_autoconf_config.hpp.in with 
these exceptions:


- "#cmakedefine var 1" is used in place of "#undef var" for Boolean macros
- "#define var @var@" is used for substitutions of types and values with 
direct replacement of the @var@, just like in configure .in files.
- It also includes the missing Windows logic which wasn't needed for the 
Unix-only autoconf template


The header is generated from the template by the configure_file in the 
root CMakeLists.txt:


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)

The @ONLY means only @var@ 

RE: Integrating CMake support for xerces

[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 much work in 
every project.

> It would have been great if there was some way to share the logic
> between the two.  The snippets of program code used for feature tests
> might be shared, but they are so small and trivial that it's likely not
> worth it.

No, it was more the overarching set of defines and how they're populated.

> One place we can definitely share code is the unit test output.  Here,
> we add test output files, one per unit test, for validating the tests.

I'm very unfamiliar with the tests but that all makes sense.

> 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?

No, the intermediates. People *want*, virtually *demand* the ability to do 
source builds with configure/make/make install and any violation of the norm is 
just painful for anybody using Xerces in their projects together with dozens of 
other libraries all expecting to be built that way. "Different" is bad in this 
context.

> While on Unix this is certainly duplicating much of the autotools logic,
> and could potentially replace autotools entirely, the real gain (and the
> intention for doing this) is the vastly improved support for Windows.

Oh, I know that, it's the concern that if we don't/can't replace the autotools 
pieces we end up needing to maintain both to keep the config.h/etc. material in 
sync and working.

> I think it's fairly simple to change; I'll have to check.  The same also
> applies to the full .so version on Unix, which isn't identical to
> libtool in its pattern.  Same name to link with, and same SOVERSION
> symlink, but the library itself has a slightly different pattern.

I'm not a fan of the non-soname versioning used, but there's backstory there 
and I don't think we want to re-litigate it, so the convention there has been 
to embed the ABI version in the name (libxerces-c-3.1.so, new one will be 
libxerces-c-3.2.so)

> The question I have here is this: why is the link name different on
> Windows?  With CMake being cross-platform, it would allow the naming and
> versioning conventions to be the same on both Unix and Windows.  This is
> a usability gain when a cross-platform downstream project wants to link
> with xerces: right now they have to hardcode the discrepancy.  I'm sure
> we can tweak it to retain the existing platform-specific conventions
> with a few additional bits of configuration, however.

Most projects don't have any cross platform build tooling for Linux and 
Windows, so the name difference doesn't really come up much. On the Windows 
side, it's critical for the ABI version tag and a D (for debug) be present, but 
I'm not personally wedded to anything in particular other than, again, not 
wanting to engage in a bikeshedding discussion about it, so leaving it 
consistent with 3.1 seemed the simplest choice.

If there's value in aligning with the Linux names, though, I'm not really 
opposed personally, but Linux doesn't have the debug/non-debug distinction 
either, so I don't think they could really be identical anyway...

I've successfully built various combinations of the Windows build and I get the 
gist of it.

I guess for myself, my comfort level would go up a bit if there was just a 
brief sort of outline of how a given AC_DEFINE or Windows #define would be 
added to the cmake build if it became needed. If I had some comfort level with 
how it works, the duplication wouldn't bother me too much.

-- Scott

Re: Integrating CMake support for xerces

[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 that it 
looks like there definitely is a lot of overlap with the material we have to 
maintain for autoconf, and I'm just concerned about the dual maintenance of it 
or the possibility of it falling out of sync since nobody else really knows 
cmake.


There's certainly a good amount of duplication, most of it intentionally 
so that the CMake logic mirrors the existing Autoconf feature tests 
exactly.  This is so it can be a drop-in replacement in every respect; 
we could have gone with a more CMake-native approach in some cases, or 
dropped some historical parts entirely.  Most if it is needed to support 
all the configurable options so that we're exactly reproducing the same 
#defines in the configuration header, and doing exactly the same 
conditional compilation.


It would have been great if there was some way to share the logic 
between the two.  The snippets of program code used for feature tests 
might be shared, but they are so small and trivial that it's likely not 
worth it.


One place we can definitely share code is the unit test output.  Here, 
we add test output files, one per unit test, for validating the tests. 
This permits individual tests to be run, run in parallel (and it also 
fixes the tests on FreeBSD where there are issues with newlines at the 
end of file for some reason).  We could make automake "make check" use 
these as well, replacing the perl script currently in use, which will 
make the autotools testing a bit more accessible and transparent, as 
well as a bit more portable.  I can certainly look at this as a followup 
task.



Leaving aside whether it's a good or bad idea, if we wanted to standardize on 
this, does the cmake system generate actual autoconf-compatible build files 
(i.e. you run configure?) or does it take over that role. I think the latter is 
a non-starter given the prevalence of autoconf assumptions across the 
landscape. And if so, that does raise maintenance concerns.


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?


CMake and its CMakeLists.txt file are equivalent to 
autoconf/automake/autoheader/libtoolize and configure.ac, Makefile.am, 
config.h.in etc. along with the generated Makefile.in/configure etc. 
CMake is a single tool which generates build files for any supported 
build system by evaluating the CMakeLists.txt script.  In the case of 
its "Unix Makefiles" generator, this generates Makefiles and headers 
just like configure, but without any intermediate scripts being needed. 
The Makefiles are broadly equivalent in terms of supported targets like 
"make install"; and when running cmake, you can configure all the 
options and path prefixes almost the same as configure (the names are 
slightly different but the intent is the same).


While on Unix this is certainly duplicating much of the autotools logic, 
and could potentially replace autotools entirely, the real gain (and the 
intention for doing this) is the vastly improved support for Windows. 
I'd suggest that the cost of the duplication is outweighed by the 
existing maintenance burden of the Visual Studio solutions, which was 
often externalised since people like myself had to hand-patch every 
release to make them work with ICU, newer Visual Studio versions etc. 
With CMake, we just run cmake with the desired options, and we're done, 
and we can directly integrate this with other projects.



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 between or use separate 
unpacked trees, etc. Is that correct?


Yes, as you mentioned in your other reply, you need to use separate 
build directories for each compiler/platform combination; you can use a 
common source tree.  On Windows, you can


- Choose the developer command prompt of your choice, and then use the 
"-G" option to select the "NMake, "Ninja" or any other generator of your 
choice.
- Use the "Visual Studio nn  [Win64]" generator from a regular 
command prompt, and it will set up the compiler environment for you; 
build with "msbuild" or open up the solution in Visual Studio.
- Use Cygwin or MinGW with the "Unix Makefiles" or any other generator 
of choice


So CMake does make building

> One issue I did notice on the Windows side is that the DLL names are
> different from the existing 

RE: Integrating CMake support for xerces

[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


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Integrating CMake support for xerces

[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 between or use separate
> unpacked trees, etc. Is that correct?

Never mind, I see the instructions now for running it in separate directories 
now.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Integrating CMake support for xerces

[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 lot of overlap with the material we have to 
maintain for autoconf, and I'm just concerned about the dual maintenance of it 
or the possibility of it falling out of sync since nobody else really knows 
cmake.

Leaving aside whether it's a good or bad idea, if we wanted to standardize on 
this, does the cmake system generate actual autoconf-compatible build files 
(i.e. you run configure?) or does it take over that role. I think the latter is 
a non-starter given the prevalence of autoconf assumptions across the 
landscape. And if so, that does raise maintenance concerns.

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 between or use separate 
unpacked trees, etc. Is that correct?

-- Scott

RE: Integrating CMake support for xerces

[Dean Roddey]

I would have been writing the original version of the parser in about 98 
probably, so C++98 would have only just come into being. Though, the thing with 
not just sharing allocated memory with the containing application was added 
later. I didn't write it that way at the start and wouldn't have ever went that 
way myself.

There definitely wasn't any Unix anti-C++ bias in the original code, since I'm 
a Windows guy and had been doing C++ for quite a few years by then. But to 
support the 9ish or more platforms we did at the time without any conditional 
code (other than the per-platform stuff and some endian sensitive code I 
guess), meant keeping it pretty plain jane.


Dean Roddey
Chairman/CTO
Charmed Quark Systems, Ltd
www.charmedquark.com


-Original Message-
From: Roger Leigh [mailto:rle...@codelibre.net] 
Sent: Wednesday, April 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 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 nicely.  Primarily the
>> lack of RAII, non-standard exception types, odd memory management 
>> semantics and transcoding all input.
>
> The problem with C++11 is it's just not portable to enough compilers outside 
> of Windows. I'm aware gcc probably supports it but gcc on actual Linux 
> distros that people still use heavily does not. If I can't build it on RH6 
> it's not usable for me, and since I'm the one doing most of the work right 
> now...
>
> Really, C++11 is beside the point. Simply good old C++ would fix many issues, 
> but this code dates to back when using real C++ and the STL was just too 
> non-portable, along with the usual Unix anti-C++ bias.

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.

Regarding portability, I also have the "pleasure" of supporting code on CentOS 
6.  I don't know if you've tried it, but we switched to using the SCL 
"devtoolset-3" (now "devtoolset-4") packages which backport a modern GCC and 
the rest of the toolchain to CentOS6 (and 7).  We use this to build C++11 code 
on CentOS 6, and it's been trouble free for us.  Apart from CentOS, we build 
C++11 without any trouble on current FreeBSD 10/11, MacOS X 10.9+, Ubuntu 
14.04/16.04 and Windows (VS2013, 15, 17 soon).  It's CentOS 6 which is 
currently the lowest common denominator; everything else has supported C++11 
well for many years at this point. 
Our projects made the switch a few months back once they were buildable and 
supportable across the board.


Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 on many 
platforms.

> Regarding portability, I also have the "pleasure" of supporting code on 
> CentOS 6.  I don't know if you've tried it, but we switched to using the 
> SCL "devtoolset-3" (now "devtoolset-4") packages which backport a modern 
> GCC and the rest of the toolchain to CentOS6 (and 7).

Do the packages built from that work on an unmodified CentOS 6 system? Meaning 
does it pull in any dependencies for that from the standard repos?

The change that's really relevant for me is that Red Hat 5 dropped out of 
standard support in March, so that was a major switch.

Unfortunately I also have many older SUSE versions to support also.

-- Scott




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 nicely.  Primarily the
lack of RAII, non-standard exception types, odd memory management
semantics and transcoding all input.


The problem with C++11 is it's just not portable to enough compilers outside of 
Windows. I'm aware gcc probably supports it but gcc on actual Linux distros 
that people still use heavily does not. If I can't build it on RH6 it's not 
usable for me, and since I'm the one doing most of the work right now...

Really, C++11 is beside the point. Simply good old C++ would fix many issues, 
but this code dates to back when using real C++ and the STL was just too 
non-portable, along with the usual Unix anti-C++ bias.


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.


Regarding portability, I also have the "pleasure" of supporting code on 
CentOS 6.  I don't know if you've tried it, but we switched to using the 
SCL "devtoolset-3" (now "devtoolset-4") packages which backport a modern 
GCC and the rest of the toolchain to CentOS6 (and 7).  We use this to 
build C++11 code on CentOS 6, and it's been trouble free for us.  Apart 
from CentOS, we build C++11 without any trouble on current FreeBSD 
10/11, MacOS X 10.9+, Ubuntu 14.04/16.04 and Windows (VS2013, 15, 17 
soon).  It's CentOS 6 which is currently the lowest common denominator; 
everything else has supported C++11 well for many years at this point. 
Our projects made the switch a few months back once they were buildable 
and supportable across the board.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 incorporating your patch.

Other than some things I have to port up from the branch and other bug reports 
that have come in, the two big commits on trunk are:

r1517488 (XERCESC-2016)
r1528170 (XERCESC-2019)

The former is a patch that's pretty invasive to add XML 1.0 5th edition 
support, which I surmise actually removes a lot of the special handling of XML 
1.1 All of that is outside my expertise, so I don't have any insight into how 
risky that change is or how well it was tested. For myself I don't need it at 
all and would as soon undo it if it can't be verified as safe, but I'm not 
suggesting that exactly, just noting it's significant.

The latter is smaller and is a change to memory handling of text buffers in the 
DOM. I haven't fully grokked that yet but I doubt it's a big deal, just worth a 
look.

Everything else on trunk now that's not on the branch is much simpler and I 
don't see as risky.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 project provide any equivalent services internally?

There are already mirrors of the code at git.apache.org (and to github from 
there), and of course all CI tools can pull from svn just as easily as git. 
That's never been an impediment. I don't know if there are tests sufficient to 
be worth exercising like that or not.

> Regarding (3), it's a bit outside the scope of this CMake ticket.  My 
> intentions here were to get a build system which would provide a working 
> build on all platforms, including the unit tests.  I didn't want to go 
> down the rabbit hole at the same time.  Ideally, if we merge this to the 
> trunk and branch off a 3.2 and release that, more adventurous changes 
> could be then done on the trunk.  I'd rather have a working release with 
> the CMake support included than to do both and not have an immediately 
> usable and API compatible release!

+1

I wasn't suggesting anything else, and it makes sense to go ahead and branch 
again if there's going to be any real screwing around, I need a stable branch 
myself.

I have made some progress today after a few hours reviewing trunk and I'm only 
about 10 commits back from when I started cherry picking things back to the 3.1 
branch, at which point the trunk essentially froze. 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 incorporating your patch.

> 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 nicely.  Primarily the 
> lack of RAII, non-standard exception types, odd memory management 
> semantics and transcoding all input.

The problem with C++11 is it's just not portable to enough compilers outside of 
Windows. I'm aware gcc probably supports it but gcc on actual Linux distros 
that people still use heavily does not. If I can't build it on RH6 it's not 
usable for me, and since I'm the one doing most of the work right now...

Really, C++11 is beside the point. Simply good old C++ would fix many issues, 
but this code dates to back when using real C++ and the STL was just too 
non-portable, along with the usual Unix anti-C++ bias.

> Something worth noting is that our 
> (optional) ICU dependency switched to requiring C++11 with ICU 59.1.  It
>  switched to using the standard char16_t as its XML string type.  If 
> Xerces were to also switch (or at least use a suitable typedef), we 
>  could be using const char16_t* foo = u"UTF-16 strings" and/or u8"UTF-8" 
> strings directly in both the xerces sources and in client programs.  A 
> major usability improvement.

At a huge cost in portability unfortunately. Believe me, I wish that were 
viable for me. So, so much.

> In a recent performance testing exercise at work, we found string 
> transcoding inside xerces-c to be a major time sink--using valgrind 
> callgrind--it was one of the major uses of CPU time during parsing and 
> DOM processing.  It was slower than xerces-j for the same operations, 
> and this was likely to be a major cause.

I'm not sure that you're going to fix that. It's already using UTF-16 
internally. If there are problems with transcoding, I think that's just the 
cost of transcoding, I don't think the need to transcode goes away unless I'm 
missing something.

Anyway, within a week or two I expect to be able to put trunk in a position to 
accept your patch and we can continue on from there.

-- Scott

Re: Integrating CMake support for xerces

[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 as
is to pretty much forking it. The main reasons for forking would
be: (1) to switch to git (life is just too short for svn), (2)
to get rid of the Apache bureaucracy, and (3) rip all the legacy
parts out and clean things up (maybe even switching to C++11/14).


(1) doesn't matter to me, but +1000 to (2) and I have very little compunction 
about (3), aside from the obvious fact that once you start pulling that thread, 
you're on slippery ground.

I wasn't prepared to really go so far as to start tossing things out or 
proposing really invasive changes but it sounds like cleaning up and releasing 
the trunk would serve both short term and longer term ends here.


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 project provide any equivalent services internally?


Regarding (3), it's a bit outside the scope of this CMake ticket.  My 
intentions here were to get a build system which would provide a working 
build on all platforms, including the unit tests.  I didn't want to go 
down the rabbit hole at the same time.  Ideally, if we merge this to the 
trunk and branch off a 3.2 and release that, more adventurous changes 
could be then done on the trunk.  I'd rather have a working release with 
the CMake support included than to do both and not have an immediately 
usable and API compatible release!


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 nicely.  Primarily the 
lack of RAII, non-standard exception types, odd memory management 
semantics and transcoding all input.  Something worth noting is that our 
(optional) ICU dependency switched to requiring C++11 with ICU 59.1.  It 
switched to using the standard char16_t as its XML string type.  If 
Xerces were to also switch (or at least use a suitable typedef), we 
could be using const char16_t* foo = u"UTF-16 strings" and/or u8"UTF-8" 
strings directly in both the xerces sources and in client programs.  A 
major usability improvement.


In a recent performance testing exercise at work, we found string 
transcoding inside xerces-c to be a major time sink--using valgrind 
callgrind--it was one of the major uses of CPU time during parsing and 
DOM processing.  It was slower than xerces-j for the same operations, 
and this was likely to be a major cause.


Certainly cleaning up and releasing trunk would be a step towards any of 
that, should there be a consensus for that.



Regards,
Roger


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

RE: Integrating CMake support for xerces

[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. The main reasons for forking would
> be: (1) to switch to git (life is just too short for svn), (2)
> to get rid of the Apache bureaucracy, and (3) rip all the legacy
> parts out and clean things up (maybe even switching to C++11/14).

(1) doesn't matter to me, but +1000 to (2) and I have very little compunction 
about (3), aside from the obvious fact that once you start pulling that thread, 
you're on slippery ground.

I wasn't prepared to really go so far as to start tossing things out or 
proposing really invasive changes but it sounds like cleaning up and releasing 
the trunk would serve both short term and longer term ends here.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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 practice so we can dismiss that one.


I can certainly rebase the cmake-3.1 branch onto trunk if that would 
make sense.  However, looking at the differences between the 3.1 branch 
and the trunk, it looks like the trunk might need a fair amount of 3.1 
work applying.  Is it a bit out of date?


I'm getting a few conflicts in EXTRA_DIST in a few Makefile.ams. 
Nothing major, but it's highlighting that there's stuff missing on the 
trunk.



Since the proposed changes don't touch any of the existing build
systems, merging onto the 3.1 branch would be safe, but since it's a
fairly large change it would be understandable to leave this for a new
minor release.  Is there any particular preference?


I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. So I'm inclined to 
do the very ugly work of figuring out what's missing from the trunk and 
reviewing all the additional work there that was done before the project went 
into moribundity, and try and get a 3.2 out the door this summer.

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.


OK.  If there's anything I can do to help out here, I can certainly try.


Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Integrating CMake support for xerces

[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.

> Since the proposed changes don't touch any of the existing build 
> systems, merging onto the 3.1 branch would be safe, but since it's a 
> fairly large change it would be understandable to leave this for a new 
> minor release.  Is there any particular preference?

I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. So I'm inclined to 
do the very ugly work of figuring out what's missing from the trunk and 
reviewing all the additional work there that was done before the project went 
into moribundity, and try and get a 3.2 out the door this summer. 

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.

> For maintenance reasons, I'd like to propose removing all the Visual Studio 
> files; this was one of the primary reasons for developing the CMake 
> support in the first place.  This would make sense to do on the 
> trunk/3.2 branch, since we wouldn't want to remove existing 
> functionality on the 3.1 branch.

Right, I think that's another good argument for using trunk.

> Removing the Autoconf support would also be a possibility if there was 
> consensus to do so.  The CMake support certainly implements all the 
> Autoconf features--it reproduces every single feature test and option 
> exactly.  But the maintenance cost is vastly less than the Visual Studio 
> support, so retaining both Autoconf and CMake support is certainly possible.

I'm not inclined to consider removint autoconf without seeing the alternative 
and understanding the implications, particularly wrt libtool.

> 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

I will do so when I can.

-- Scott