[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-29 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch
0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch
0003-cmake-Check-for-char16_t.patch
0004-autoconf-Check-for-char16_t.patch
0005-tests-Add-Char16Test.patch

In the absence of a response, I've rewritten the patch myself in the interest 
of getting this in.

Builds passed in 
https://travis-ci.org/rleigh-codelibre/xerces-c/builds/258621587 and 
https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.116

Would this be OK to merge?

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>    Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0003-cmake-Check-for-char16_t.patch, 0003-cmake-Check-for-char16_t.patch, 
> 0004-autoconf-Check-for-char16_t.patch, 
> 0004-autoconf-Check-for-char16_t.patch, 0005-tests-Add-Char16Test.patch, 
> 0005-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-29 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 
0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>    Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0003-cmake-Check-for-char16_t.patch, 0003-cmake-Check-for-char16_t.patch, 
> 0004-autoconf-Check-for-char16_t.patch, 
> 0004-autoconf-Check-for-char16_t.patch, 0005-tests-Add-Char16Test.patch, 
> 0005-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-29 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0003-cmake-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>    Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, 
> 0005-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-29 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0005-tests-Add-Char16Test.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>    Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, 
> 0005-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-29 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0004-autoconf-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>    Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, 
> 0005-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (XERCESC-2113) Base64.cpp missing config.h include

2017-08-08 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2113:


 Summary: Base64.cpp missing config.h include
 Key: XERCESC-2113
 URL: https://issues.apache.org/jira/browse/XERCESC-2113
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.2.0
Reporter: Roger Leigh


{{{
13:04:43 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
 error: use of undeclared identifier 'XERCES_SIZE_MAX'
13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) {
13:04:43  ^
}}}

I think this is because of a missing stdint.h include.  This is provided by 
config.h, but there's no config.h include in Base64.cpp.  Other platforms must 
be getting this via an indirect include.

Note that this also has other portability implications (though they don't need 
tackling right now).  Using size_t implies using SIZE_MAX, but SIZE_MAX 
requires stdint.h.  stdint.h was previously optional, with fallbacks used if 
not present, but this makes it effectively mandatory, making all of the other 
integer portability logic redundant.  i.e. we could just require 
stdint.h/cstdint unconditionally and drop all of the other logic.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2113) Base64.cpp missing config.h include

2017-08-08 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2113:
-
Component/s: Build

> Base64.cpp missing config.h include
> ---
>
> Key: XERCESC-2113
> URL: https://issues.apache.org/jira/browse/XERCESC-2113
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>
> {{{
> 13:04:43 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
>  error: use of undeclared identifier 'XERCES_SIZE_MAX'
> 13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) {
> 13:04:43  ^
> }}}
> I think this is because of a missing stdint.h include.  This is provided by 
> config.h, but there's no config.h include in Base64.cpp.  Other platforms 
> must be getting this via an indirect include.
> Note that this also has other portability implications (though they don't 
> need tackling right now).  Using size_t implies using SIZE_MAX, but SIZE_MAX 
> requires stdint.h.  stdint.h was previously optional, with fallbacks used if 
> not present, but this makes it effectively mandatory, making all of the other 
> integer portability logic redundant.  i.e. we could just require 
> stdint.h/cstdint unconditionally and drop all of the other logic.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Closed] (XERCESC-2113) Base64.cpp missing config.h include

2017-08-08 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh closed XERCESC-2113.

Resolution: Invalid

This one is a bit strange.  Building xerces in isolation, everything is working 
fine.

This is working:

cd 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2/src
 && /usr/bin/CC  -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
-D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -isystem 
/usr/local/include 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2
 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src
 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2/src
 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 
-Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long 
-Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder 
-Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros 
-fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC   -pthread -std=gnu++14 -o 
CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp

This is failing:

cd 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
 && /usr/bin/CC  -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
-D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -I/usr/local/include 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build
 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src
 
-I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
 -isystem 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 
-Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long 
-Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder 
-Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros 
-fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC   -pthread -std=gnu++14 -o 
CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c 
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
 error: 
  use of undeclared identifier 'XERCES_SIZE_MAX'
else if (XERCES_SIZE_MAX - inputLength < 2) {
 ^
1 error generated.

It's all down to using -I/usr/local/include and not -isystem /usr/local/include 
which is a bit odd.  

If I update Base64.cpp to include config.h, I get a warning about

/usr/local/include/xercesc/util/Xerces_autoconf_config.hpp:65:9: warning: 
'XERCES_XMLCH_T' macro redefined [-Wmacro-redefined]

but it all works.  But it then fails with

[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinInputStream.cpp.o
/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/BinInputStream.cpp:48:30:
 error: 
  out-of-line definition of 'getEncoding' does not match any declaration in 
'xercesc_3_1::BinInputStream'
const XMLCh* BinInputStream::getEncoding() const
 ^~~

I think what's happening here is that the xerces 3.1 headers in /usr/local are 
being included in preference to those in the source tree.  This is definitely 
not a xerces problem; it's my problem, so I'll close this.

> Base64.cpp missing config.h include
> ---
>
> Key: XERCESC-2113
> URL: https://issues.apache.org/jira/browse/XERCESC-2113
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>Reporter: Roger Leigh
>
> {{{
> 13:04:43 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
>  error: use of undeclared identifier 'XERCES_SIZE_MAX'
> 13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) {
> 13:04:43  ^
> }}}
> I think this is because of a missing stdint.h include.  This is provided by 
> config.h, but there's no config.h include in Base64.cpp.  Other platforms 
> must be getting this via an indirect include.
> No

[jira] [Created] (XERCESC-2114) Link failure with Xalan-C

2017-08-08 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2114:


 Summary: Link failure with Xalan-C
 Key: XERCESC-2114
 URL: https://issues.apache.org/jira/browse/XERCESC-2114
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.2.0
 Environment: VS2013 on Windows Server 2012R2
Reporter: Roger Leigh


Testing latest rc1 with xalan and VS2013:

[Build 
log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]

Using [this 
patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
 to build Xalan with VS2013 (it's just the upgraded project files).

{noformat}
12:29:32(Link target) -> 
12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: unresolved 
external symbol "__declspec(dllimport) unsigned __int64 const `public: static 
unsigned __int64 __cdecl 
xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
__int64)'::`2'::alignment" 
(__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
 
[D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
12:29:32  ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : fatal 
error LNK1120: 1 unresolved externals 
[D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
{noformat}

Is there any incompatible change expected here?  Could potentially be missing 
symbol exports or anything of that nature?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2114) Link failure with Xalan-C

2017-08-08 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118558#comment-16118558
 ] 

Roger Leigh commented on XERCESC-2114:
--

It may well be Xalan to blame, and I'll try to find time to investigate this 
more closely tomorrow.  I don't imagine that the exports are faulty because all 
the unit tests and samples work perfectly.

> Link failure with Xalan-C
> -
>
> Key: XERCESC-2114
> URL: https://issues.apache.org/jira/browse/XERCESC-2114
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: VS2013 on Windows Server 2012R2
>Reporter: Roger Leigh
>
> Testing latest rc1 with xalan and VS2013:
> [Build 
> log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]
> Using [this 
> patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
>  to build Xalan with VS2013 (it's just the upgraded project files).
> {noformat}
> 12:29:32(Link target) -> 
> 12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: 
> unresolved external symbol "__declspec(dllimport) unsigned __int64 const 
> `public: static unsigned __int64 __cdecl 
> xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
> __int64)'::`2'::alignment" 
> (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
>  
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> 12:29:32  ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : 
> fatal error LNK1120: 1 unresolved externals 
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> {noformat}
> Is there any incompatible change expected here?  Could potentially be missing 
> symbol exports or anything of that nature?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2110) Build failure on FreeBSD with Autoconf

2017-08-07 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2110.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

Also fixed by the config.h inclusion added in #2110.

> Build failure on FreeBSD with Autoconf
> --
>
> Key: XERCESC-2110
> URL: https://issues.apache.org/jira/browse/XERCESC-2110
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: FreeBSD 11.1 with clang 4.0.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
> Fix For: 3.2.0
>
>
> Looks like illegal arithmetic with time_t?
> {{{
> make  all-am
>   CXX  xercesc/util/XMLDateTime.lo
> ../../xerces-c-3.2.0/src/xercesc/util/XMLDateTime.cpp:571:27: error: invalid 
> operands to binary expression ('time_t' (aka 'long') and 'char *(*)(int, 
> int)')
> return mktime() - timezone;
>~~ ^ 
> 1 error generated.
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2109) Build failure on FreeBSD with CMake

2017-08-07 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2109.
--
Resolution: Fixed

Fixed in r1804297.

> Build failure on FreeBSD with CMake
> ---
>
> Key: XERCESC-2109
> URL: https://issues.apache.org/jira/browse/XERCESC-2109
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: FreeBSD 11.1 with clang 4.0.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
> Fix For: 3.2.0
>
>
> {{{
> 19:20:26 cd 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
>  && /usr/bin/CC  -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I/usr/local/include 
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build
>  
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src
>  
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
>  -isystem 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
>   -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 
> -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long 
> -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder 
> -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros 
> -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC   -pthread -std=gnu++14 -o 
> CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp
> 19:20:26 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
>  error: use of undeclared identifier 'XERCES_SIZE_MAX'
> 19:20:26 else if (XERCES_SIZE_MAX - inputLength < 2) {
> 19:20:26  ^
> 19:20:26 1 error generated.
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2109) Build failure on FreeBSD with CMake

2017-08-07 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116293#comment-16116293
 ] 

Roger Leigh commented on XERCESC-2109:
--

Fixed in r1804297.  There were two problems here.  One was that CMake requires 
updates to config.h.cmake.in (there's no direct equivalent to autoheader, 
unfortunately--I could probably write one).  The second was that config.h 
wasn't included in XMLDateTime.cpp, so it was failing anyway on any platform 
where the fallback failed.

> Build failure on FreeBSD with CMake
> ---
>
> Key: XERCESC-2109
> URL: https://issues.apache.org/jira/browse/XERCESC-2109
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: FreeBSD 11.1 with clang 4.0.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
> Fix For: 3.2.0
>
>
> {{{
> 19:20:26 cd 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
>  && /usr/bin/CC  -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I/usr/local/include 
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build
>  
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src
>  
> -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src
>  -isystem 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include
>   -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 
> -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long 
> -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder 
> -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros 
> -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC   -pthread -std=gnu++14 -o 
> CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp
> 19:20:26 
> /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14:
>  error: use of undeclared identifier 'XERCES_SIZE_MAX'
> 19:20:26 else if (XERCES_SIZE_MAX - inputLength < 2) {
> 19:20:26  ^
> 19:20:26 1 error generated.
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013

2017-08-07 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116681#comment-16116681
 ] 

Roger Leigh commented on XERCESC-2111:
--

Also note 
https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010

We use this in libtiff like so: 
https://github.com/vadz/libtiff/blob/master/port/snprintf.c and this CMake 
logic: https://github.com/vadz/libtiff/blob/master/port/CMakeLists.txt#L42 and 
this autoconf logic: 
https://github.com/vadz/libtiff/blob/master/configure.ac#L429

I could look at implementing this in Xerces if you like.

> Build failure with Windows and VS2013
> -
>
> Key: XERCESC-2111
> URL: https://issues.apache.org/jira/browse/XERCESC-2111
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows Server 2008R2 with Visual Studio 2013
>Reporter: Roger Leigh
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
>
> snprintf isn't available before VS2015, though a Microsoft-specific variant 
> is available which we could use conditionally.  However, even this is not 
> present in earlier Visual Studio releases.  Do we strictly need to use 
> snprintf here?  If we do, how far back do our Visual Studio portability 
> requirements go?
> {{{
> 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP 
> -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I. 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src
>  -Isrc 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include
>  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes 
> /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj 
> /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480)
>  : error C3861: 'snprintf': identifier not found
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Comment Edited] (XERCESC-2111) Build failure with Windows and VS2013

2017-08-07 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116725#comment-16116725
 ] 

Roger Leigh edited comment on XERCESC-2111 at 8/7/17 3:15 PM:
--

I would personally be fine with STL and ostringstream or equivalent.  At worst, 
it increases the compile time of a few files slightly.  It's more portable than 
snprintf given Microsoft's previous lack of support for C and C99, so would be 
an obvious safe replacement.  I use them all the time without trouble, and you 
can even imbue streams with locales for more control over serialisation should 
we care about e.g. stable number formatting etc.


was (Author: rleigh):
I would personally be fine with STL and ostringstream or equivalent.  At worst, 
it increases the compile time of a few files slightly.  It's more portable than 
snprintf given Microsoft's previous lack of support for C and C99, so would be 
an obvious safe replacement.  I use them all the time without trouble, and you 
can even imbue streams with locales for more control over serialisation should 
be care about e.g. stable number formatting etc.

> Build failure with Windows and VS2013
> -
>
> Key: XERCESC-2111
> URL: https://issues.apache.org/jira/browse/XERCESC-2111
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows Server 2008R2 with Visual Studio 2013
>Reporter: Roger Leigh
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
>
> snprintf isn't available before VS2015, though a Microsoft-specific variant 
> is available which we could use conditionally.  However, even this is not 
> present in earlier Visual Studio releases.  Do we strictly need to use 
> snprintf here?  If we do, how far back do our Visual Studio portability 
> requirements go?
> {{{
> 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP 
> -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I. 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src
>  -Isrc 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include
>  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes 
> /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj 
> /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480)
>  : error C3861: 'snprintf': identifier not found
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013

2017-08-07 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116725#comment-16116725
 ] 

Roger Leigh commented on XERCESC-2111:
--

I would personally be fine with STL and ostringstream or equivalent.  At worst, 
it increases the compile time of a few files slightly.  It's more portable than 
snprintf given Microsoft's previous lack of support for C and C99, so would be 
an obvious safe replacement.  I use them all the time without trouble, and you 
can even imbue streams with locales for more control over serialisation should 
be care about e.g. stable number formatting etc.

> Build failure with Windows and VS2013
> -
>
> Key: XERCESC-2111
> URL: https://issues.apache.org/jira/browse/XERCESC-2111
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows Server 2008R2 with Visual Studio 2013
>Reporter: Roger Leigh
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
>
> snprintf isn't available before VS2015, though a Microsoft-specific variant 
> is available which we could use conditionally.  However, even this is not 
> present in earlier Visual Studio releases.  Do we strictly need to use 
> snprintf here?  If we do, how far back do our Visual Studio portability 
> requirements go?
> {{{
> 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP 
> -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I. 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src
>  -Isrc 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include
>  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes 
> /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj 
> /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480)
>  : error C3861: 'snprintf': identifier not found
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013

2017-08-07 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116773#comment-16116773
 ] 

Roger Leigh commented on XERCESC-2111:
--

I've tested with VS2013 and the sprintf workaround is working fine (just a 
compiler warning), so I think this is fine as it is for 3.2.0, but we could 
look at sstream for the future if using the STL is allowed (I'd still like to 
use standard exceptions, but probably too late for 3.2.x at this point).

> Build failure with Windows and VS2013
> -
>
> Key: XERCESC-2111
> URL: https://issues.apache.org/jira/browse/XERCESC-2111
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows Server 2008R2 with Visual Studio 2013
>Reporter: Roger Leigh
>Assignee: Scott Cantor
> Fix For: 3.2.0
>
>
> snprintf isn't available before VS2015, though a Microsoft-specific variant 
> is available which we could use conditionally.  However, even this is not 
> present in earlier Visual Studio releases.  Do we strictly need to use 
> snprintf here?  If we do, how far back do our Visual Studio portability 
> requirements go?
> {{{
> 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe   /nologo /TP 
> -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 
> -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS 
> -I. 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src
>  -Isrc 
> -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include
>  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes 
> /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj 
> /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477)
>  : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned 
> long', possible loss of data
> 17:53:44 
> D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480)
>  : error C3861: 'snprintf': identifier not found
> }}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2077) Add CMake build system

2017-05-09 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2077:
-
Attachment: screenshot-xerces-ci-tests-trunk.png

I've re-run the tests on our jenkins CI nodes.  This repeated the previous 
tests described above, and all builds and tests passed.  This tested FreeBSD 
(40 configuration combinations), Linux (80), MacOSX (40); and for Windows this 
included Cygwin (16), MinGW64 (16) and MSVC (64); totalling 256 unique 
configuration/platform combinations.

I'm afraid that due to a recent jenkins security advisory, the jenkins jobs are 
not currently accessible to the outside world, so I've attached a screenshot 
showing the job status.  This demonstrates that the cmake support is robust and 
hasn't regressed when rebased onto the trunk.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don

[jira] [Updated] (XERCESC-2077) Add CMake build system

2017-05-18 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2077:
-
Attachment: 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch

Updated patch to match library versioning with the existing build systems.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. transitive depende

[jira] [Updated] (XERCESC-2077) Add CMake build system

2017-05-18 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2077:
-
Attachment: (was: 
0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch)

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. transitive dependencies.
> - Installs the HTML documentation
> - Targets are provided for regenerating the documentation (docs and
>   apidocs)
>

[jira] [Updated] (XERCESC-2077) Add CMake build system

2017-05-17 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2077:
-
Attachment: 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch

Update to fix library versioning on Windows and Unix to retain full backward 
compatibility.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. t

[jira] [Commented] (XERCESC-2077) Add CMake build system

2017-05-09 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002880#comment-16002880
 ] 

Roger Leigh commented on XERCESC-2077:
--

That's fine, thanks.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. transitive dependencies.
> - Installs the HTML documentation
> - Targets are provided for regenerating the documentation (docs and
>   apidocs)
> - Documentation can be ed

[jira] [Created] (XERCESC-2099) Support Standard C++ mutex

2017-06-09 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2099:


 Summary: Support Standard C++ mutex
 Key: XERCESC-2099
 URL: https://issues.apache.org/jira/browse/XERCESC-2099
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.2.0
 Environment: Any supported platform
Reporter: Roger Leigh
 Attachments: 0001-StdMutexMgr-Add-C-11-mutex-manager.patch

Xerces-C currently supports POSIX and Win32 threading models with dedicated 
mutex manager classes.  C++ standards since C\+\+11 support native mutexes 
which will work on any supported platform.

The attached patch adds a {{StdMutexMgr}} class and the necessary Autoconf and 
CMake logic to check if C\+\+ mutexes are available.  If not, it will fall back 
to the existing managers.

On all but the most current compilers, it will continue to use POSIX/Win32 
managers.  On the most recent compilers, which default to C\+\+14, the standard 
mutexes will be used.  On older compilers, the user must explicitly enable by 
setting {{CXXFLAGS=-std=c++11}} or later.

See

- [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241340724]
- 
[appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.88]

for build and test results.  You'll see that GCC on Linux is using POSIX mutex, 
while clang on MacOS X is using standard mutex.  On Windows, Cygwin uses POSIX 
mutex while MinGW and MSVC uses standard mutex.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-2099) Support Standard C++ mutex

2017-06-09 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045071#comment-16045071
 ] 

Roger Leigh commented on XERCESC-2099:
--

Part of the motivation for this work is investigation into occasional random 
{{ThreadTest}} failures on FreeBSD which I've been noticing for some time, but 
haven't yet pinned down a cause.

> Support Standard C++ mutex
> --
>
> Key: XERCESC-2099
> URL: https://issues.apache.org/jira/browse/XERCESC-2099
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.2.0
> Environment: Any supported platform
>Reporter: Roger Leigh
>  Labels: c++11, mutex
> Attachments: 0001-StdMutexMgr-Add-C-11-mutex-manager.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Xerces-C currently supports POSIX and Win32 threading models with dedicated 
> mutex manager classes.  C++ standards since C\+\+11 support native mutexes 
> which will work on any supported platform.
> The attached patch adds a {{StdMutexMgr}} class and the necessary Autoconf 
> and CMake logic to check if C\+\+ mutexes are available.  If not, it will 
> fall back to the existing managers.
> On all but the most current compilers, it will continue to use POSIX/Win32 
> managers.  On the most recent compilers, which default to C\+\+14, the 
> standard mutexes will be used.  On older compilers, the user must explicitly 
> enable by setting {{CXXFLAGS=-std=c++11}} or later.
> See
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241340724]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.88]
> for build and test results.  You'll see that GCC on Linux is using POSIX 
> mutex, while clang on MacOS X is using standard mutex.  On Windows, Cygwin 
> uses POSIX mutex while MinGW and MSVC uses standard mutex.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems

2017-06-21 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057108#comment-16057108
 ] 

Roger Leigh commented on XERCESC-2102:
--

I can certainly run Java 1.6 in an old virtual machine if need be.

Regarding wikis, how about conversion to markdown?  It's supported by several 
wikis, but it also has the nice properly of being supported by GitHub, GitLab 
and others, so you can directly browse the documentation in the repo and have 
it nicely rendered.  It would keep the maintenance burden low, and it's pretty 
accessible for anyone who wanted to work on any docs changes.

> Documentation is not generatable on modern systems
> --
>
> Key: XERCESC-2102
> URL: https://issues.apache.org/jira/browse/XERCESC-2102
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>    Reporter: Roger Leigh
>
> The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}.  
> Unfortunately this tool appears to no longer be developed and it no longer 
> works with contemporary JREs due to relying upon 
> {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present.  It's 
> achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming 
> increasingly difficult to make work.
> Was there ever a migration path from slidebook to any other format which is 
> currently supported?
> Would there be any interest in moving to a contemporary documentation format, 
> and if so are there any preferred formats?  At work we use Sphinx.  I'd be 
> happy to spend a few hours converting it to this or some other format which 
> is currently supported.
> Regards,
> Roger
> {noformat}
> % make createdocs   
> [StyleBook] Overriding 
> targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".")
> [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml"
> [BasicEngine] Initializing
> [Loader] Parsing Project file
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl"
> [XalanProcessor] Applying XSL sheet 
> "sbk:/style/stylesheets/directory2project.xsl"
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (1)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (2)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (3)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (4)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (5)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (6)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (7)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (8)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (9)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (10)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (11)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (12)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (13

[jira] [Updated] (XERCESC-2077) Add CMake build system

2017-05-18 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2077:
-
Description: 
h4. Introduction

The attached patch implements a CMake build for Xerces-C++.

I have spent significant effort performing a "comprehensive" conversion of the 
existing GNU autotools and MSVC project file logic to a unified CMake build 
which supports all platforms with a single set of build files, as well as 
testing it exhaustively (see below). The existing GNU autotools build and MSVC 
project builds will continue to function and are unaffected by this addition.

h5. References

- http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
- http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
- https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1

h4. Background

CMake is a meta-build system which generates the build files for a specified 
build system, such as make, Visual Studio msbuild, nmake, ninja or a number of 
other build tools and IDEs.  This allows Xerces-C++ to be built on any 
supported platform with the native tools for that platform.

The reason why I originally needed this was due to the large maintenance burden 
of patching the provided Visual Studio project files, both for fixing bugs in 
those files and in being able to support versions of Visual Studio which aren't 
yet supported by the provided project files or for unsupported configurations 
e.g. Clang/C2, other platforms etc.  The lack of an install target also meant 
that to integrate this with a larger build required manually copying bits out 
of the build tree.  The cost of debugging and patching the existing project 
files for use in our CI builds was getting too great--maintaining and using 
this CMake build out of tree will be cheaper and more robust.  However, given 
that other people have also requested such support in the past, I thought it 
might benefit others to have this merged upstream so that it would be available 
to the benefit of all.

I have done a direct conversion of every autoconf option and feature test.  
Where there wasn't a direct CMake equivalent, I've written each feature test to 
exactly match the autoconf behaviour.  The automake Makefile.am logic is 
directly represented in the corresponding CMakeLists.txt files.  Broadly:

||Autotools||CMake||
|{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
|{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
|{{m4/*}}|{{cmake/*}}|
|{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
|_autoheader_|config.h.cmake.in|
|{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
|{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
|{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
{{samples/expected/\*}} (individual log files)|

And there's a section added to the documentation giving an overview of how to 
use it, in the same style as the autotools section.

h5. Enhancements over the existing build systems

- Universal build for any platform and build system supported by CMake
- Full support for feature and library detection on Windows, including
  discovery of ICU libraries; it's no longer static, using (long broken)
  ICU configurations in the project files
- An install target now exists on Windows, so the various pieces don't
  need manually copying out of the build tree
- Parallel build speed improvements when using ninja to replace make
  or msbuild; the speedup with the latter is significant
- Export of CMake configuration in addition to pkg-config, to make
  Xerces-C++ integrate with downstream projects using Xerces-C++ and
  cmake; this includes all dependency information of the libraries
  Xerces was linked with, i.e. transitive dependencies.
- Installs the HTML documentation
- Targets are provided for regenerating the documentation (docs and
  apidocs)
- Documentation can be edited and rebuilt from within Visual Studio
- Unit tests can be run on all supported platforms
- Unit tests can be run in parallel
- Unit tests verify individual test output on all platforms
- Unit tests can be run from within Visual Studio
- All the Visual Studio projects are grouped into categories
  (Documentation, Library, Samples, Tests), making it neater and
  easier to navigate than with the existing solution files

h5. Known differences:

- The library naming differences have been resolved.  On Unix platforms the 
libtool -release conventions are followed.  On Windows with Visual Studio the 
project file conventions are followed.

h4. Maintenance

The logic in all files directly matches the corresponding autotools files to 
the maximum extent possible.  For most updates to the autotools logic, the 
corresponding cmake change should be trivial and obvious, for example adding or 
removing source files from src/Makefile.am o

[jira] [Commented] (XERCESC-2075) Small corrections for Cygwin and MacOS X build instructions

2017-06-03 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036106#comment-16036106
 ] 

Roger Leigh commented on XERCESC-2075:
--

Would there be any objection to committing these small fixes on the trunk 
and/or 3.1?

> Small corrections for Cygwin and MacOS X build instructions
> ---
>
> Key: XERCESC-2075
> URL: https://issues.apache.org/jira/browse/XERCESC-2075
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 3.1.4
>    Reporter: Roger Leigh
>Priority: Minor
> Attachments: 
> 0001-doc-build-Some-features-don-t-work-with-Cygwin.patch, 
> 0002-doc-build-Recommend-DYLD_FALLBACK_LIBRARY_PATH-rathe.patch
>
>
> Small corrections and improvements for the build instructions.  See attached 
> patches.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (XERCESC-2077) Add CMake build system

2017-06-03 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2077.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

The two patches were committed to the trunk in revision 1797546.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Fix For: 3.2.0
>
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, 
> screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. transitive dependencie

[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-08 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Description: 
The project does not currently have any continuous integration in place.  I've 
spent the last few days getting a working solution to consider.  The attached 
patch files add support for two commonly used services, 
[Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] 
(Windows).

See this [GitHub 
branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
commit has a green tick mark, which is the CI status.  This links through to 
the build results:

- 
[Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
- 
[AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]

How to use this?  Go to the Travis or AppVeyor websites and log in with 
GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
the service for your xerces-c git repo.  Now any branch you push to your git 
repo will be automatically built in several configuration combinations for 
Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
2015).  The exact combinations tested are viewable with the above build links, 
or in the attached patch files.  The set of test combinations can be adjusted 
as desired.

This could additionally be enabled for the Apache GitHub mirror or the Apache 
git repo itself, which would trigger builds for all subversion commits to do 
post-commit testing.

Would there be any objection to committing these changes?

  was:
The project does not currently have any continuous integration in place.  I've 
spent the last few days getting a working solution to consider.  The attached 
patch files add support for two commonly used services, 
[Travis|https://travis-ci.org/] (Unix) and [AppVeyor|www.appveyor.com] 
(Windows).

See this [GitHub 
branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
commit has a green tick mark, which is the CI status.  This links through to 
the build results:

- 
[Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
- 
[AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]

How to use this?  Go to the Travis or AppVeyor websites and log in with 
GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
the service for your xerces-c git repo.  Now any branch you push to your git 
repo will be automatically built in several configuration combinations for 
Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
2015).  The exact combinations tested are viewable with the above build links, 
or in the attached patch files.  The set of test combinations can be adjusted 
as desired.

This could additionally be enabled for the Apache GitHub mirror or the Apache 
git repo itself, which would trigger builds for all subversion commits to do 
post-commit testing.

Would there be any objection to committing these changes?


> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 0001-samples-Makefile.am-Add-missing-continuation.patch, 
> 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0003-ci-Add-travis-support-for-Linux.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - 
> [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you p

[jira] [Commented] (XERCESC-2048) Error during build on Windows/MinGW because of LDFLAGS=-no-undefined

2017-06-08 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043033#comment-16043033
 ] 

Roger Leigh commented on XERCESC-2048:
--

The new CMake support on the trunk will allow building and testing with MinGW, 
e.g. 
https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76/job/4vo6enhkhday4a72

> Error during build on Windows/MinGW because of LDFLAGS=-no-undefined 
> -
>
> Key: XERCESC-2048
> URL: https://issues.apache.org/jira/browse/XERCESC-2048
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.2, 3.1.3
> Environment: Windows 8.1 with MinGW
>Reporter: Philip Young
>Priority: Blocker
>
> Followed the build instructions and used ./configure LDFLAGS=-no-undefined
> config.log shows the following:
> Target: mingw32
> Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 
> --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld 
> --enable-lto --enable-libssp --disable-multilib 
> --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions 
> --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug 
> --enable-version-specific-runtime-libs 
> --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld 
> --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= 
> --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp 
> --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw 
> --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
> Thread model: win32
> gcc version 4.8.1 (GCC) 
> configure:3781: $? = 0
> configure:3770: g++ -V >&5
> g++.exe: error: unrecognized command line option '-V'
> g++.exe: fatal error: no input files
> compilation terminated.
> configure:3781: $? = 1
> configure:3770: g++ -qversion >&5
> g++.exe: error: unrecognized command line option '-qversion'
> g++.exe: fatal error: no input files
> compilation terminated.
> configure:3781: $? = 1
> configure:3801: checking whether the C++ compiler works
> configure:3823: g++   -no-undefined conftest.cpp  >&5
> g++.exe: error: unrecognized command line option '-no-undefined'
> configure:3827: $? = 1
> configure:3865: result: no
> configure: failed program was:
> | /* confdefs.h */



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-08 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Attachment: (was: 
0001-samples-Makefile.am-Add-missing-continuation.patch)

> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 
> 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0003-ci-Add-travis-support-for-Linux.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - 
> [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your git 
> repo will be automatically built in several configuration combinations for 
> Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
> 2015).  The exact combinations tested are viewable with the above build 
> links, or in the attached patch files.  The set of test combinations can be 
> adjusted as desired.
> This could additionally be enabled for the Apache GitHub mirror or the Apache 
> git repo itself, which would trigger builds for all subversion commits to do 
> post-commit testing.
> Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (XERCESC-2098) Add support for external continuous integration services

2017-06-08 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2098:


 Summary: Add support for external continuous integration services
 Key: XERCESC-2098
 URL: https://issues.apache.org/jira/browse/XERCESC-2098
 Project: Xerces-C++
  Issue Type: Test
  Components: Miscellaneous
Affects Versions: 3.2.0
 Environment: Unix/Linux
Windows (MSVC, Cygwin, MinGW)
Reporter: Roger Leigh
 Attachments: 0001-samples-Makefile.am-Add-missing-continuation.patch, 
0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
0003-ci-Add-travis-support-for-Linux.patch

The project does not currently have any continuous integration in place.  I've 
spent the last few days getting a working solution to consider.  The attached 
patch files add support for two commonly used services, 
[Travis|https://travis-ci.org/] (Unix) and [AppVeyor|www.appveyor.com] 
(Windows).

See this [GitHub 
branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
commit has a green tick mark, which is the CI status.  This links through to 
the build results:

- 
[Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
- 
[AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]

How to use this?  Go to the Travis or AppVeyor websites and log in with 
GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
the service for your xerces-c git repo.  Now any branch you push to your git 
repo will be automatically built in several configuration combinations for 
Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
2015).  The exact combinations tested are viewable with the above build links, 
or in the attached patch files.  The set of test combinations can be adjusted 
as desired.

This could additionally be enabled for the Apache GitHub mirror or the Apache 
git repo itself, which would trigger builds for all subversion commits to do 
post-commit testing.

Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms

2017-06-08 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043025#comment-16043025
 ] 

Roger Leigh commented on XERCESC-1785:
--

Please see https://issues.apache.org/jira/browse/XERCESC-2098 for an attempt to 
automatically test on a range of common platforms.

Looking at the platform list on the linked wiki page, it's quite out of date.  
Do we have a current list of platforms we should be supporting?

> Build and test on all supported platforms
> -
>
> Key: XERCESC-1785
> URL: https://issues.apache.org/jira/browse/XERCESC-1785
> Project: Xerces-C++
>  Issue Type: Task
>  Components: Build
>Reporter: Boris Kolpackov
>Priority: Blocker
> Fix For: 3.2.0
>
>
> We need to make sure that building, testing and installation work on all 
> platforms that we have committed to support. See the following Wiki page for 
> the status:
> http://wiki.apache.org/xerces/XercescBuildStatus



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms

2017-06-08 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043052#comment-16043052
 ] 

Roger Leigh commented on XERCESC-1785:
--

I can certainly look at adding MacOS X to the work linked above; it's available 
as a supported platform, and it would ensure that the cfurl and 
macosxunicodeconverter options are in the test matrix.  It's currently 64-bit 
only; probably fine for commit testing; the matrix could be extended to 32-bits 
for releases if we wanted, but if we're happy with source-only releases it's 
probably easier to delegate that to distributions for the most part.  AppVeyor 
does produce downloadable zips, so we could link to Windows builds if we 
wanted, or just let people build their own.

> Build and test on all supported platforms
> -
>
> Key: XERCESC-1785
> URL: https://issues.apache.org/jira/browse/XERCESC-1785
> Project: Xerces-C++
>  Issue Type: Task
>  Components: Build
>Reporter: Boris Kolpackov
>Priority: Blocker
> Fix For: 3.2.0
>
>
> We need to make sure that building, testing and installation work on all 
> platforms that we have committed to support. See the following Wiki page for 
> the status:
> http://wiki.apache.org/xerces/XercescBuildStatus



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (XERCESC-2078) iconv message loader won't build when using current automake

2017-06-04 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2078.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

SVN revision 1797568.

> iconv message loader won't build when using current automake
> 
>
> Key: XERCESC-2078
> URL: https://issues.apache.org/jira/browse/XERCESC-2078
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
>    Reporter: Roger Leigh
>  Labels: autotools, build, iconv, patch
> Fix For: 3.2.0
>
> Attachments: 
> 0001-build-Correct-use-of-mkdir_p-with-current-automake.patch
>
>
> The existing {{Makefile.in}} in {{src/xerces/util/MsgLoader/MsgCatalog` uses 
> `$(mkdir_p)}}.  However, with current (and not so current) automake versions 
> this is set to {{$(MKDIR_P)}}, but this variable is unset, leading to a 
> failed build:
> {{gmake[4]: ../../../../../src/.libs: Command not found}}
> (from 
> [build|https://ci.openmicroscopy.org/view/Experimental/job/XERCESC-AUTOTOOLS-BSD/build_type=Release,config=4,generator=Unix%20Makefiles,label=perch,shared=OFF/14/console])
> The attached patch substitutes the missing variable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-2078) iconv message loader won't build when using current automake

2017-06-03 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036107#comment-16036107
 ] 

Roger Leigh commented on XERCESC-2078:
--

Would there be any objection to committing this one liner to the trunk and/or 
3.1?

> iconv message loader won't build when using current automake
> 
>
> Key: XERCESC-2078
> URL: https://issues.apache.org/jira/browse/XERCESC-2078
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
>    Reporter: Roger Leigh
>  Labels: autotools, build, iconv, patch
> Attachments: 
> 0001-build-Correct-use-of-mkdir_p-with-current-automake.patch
>
>
> The existing {{Makefile.in}} in {{src/xerces/util/MsgLoader/MsgCatalog` uses 
> `$(mkdir_p)}}.  However, with current (and not so current) automake versions 
> this is set to {{$(MKDIR_P)}}, but this variable is unset, leading to a 
> failed build:
> {{gmake[4]: ../../../../../src/.libs: Command not found}}
> (from 
> [build|https://ci.openmicroscopy.org/view/Experimental/job/XERCESC-AUTOTOOLS-BSD/build_type=Release,config=4,generator=Unix%20Makefiles,label=perch,shared=OFF/14/console])
> The attached patch substitutes the missing variable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047667#comment-16047667
 ] 

Roger Leigh commented on XERCESC-2100:
--

I've opened the ticket here in case anyone wanted to have a look over them and 
approve the changes.  If there are no concerns with them, would it be OK to 
commit these on the trunk?

Thanks,
Roger

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047971#comment-16047971
 ] 

Roger Leigh commented on XERCESC-2100:
--

The main thing I can see in favour of a non-virtual dtor is not having a vtable 
and saving one pointer per parent class.  But that may be a premature 
optimisation to make, and I'd personally value correctness and stability over a 
tiny performance gain.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047918#comment-16047918
 ] 

Roger Leigh commented on XERCESC-2100:
--

Yes, the reinterpret_cast instances look dodgy due to the alignment 
requirements; at least they are all easily found with grep when in the C++ form 
of the cast for future fixing.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047953#comment-16047953
 ] 

Roger Leigh commented on XERCESC-2100:
--

For 0012, it's something which GCC/clang were warning about.  But looking at 
the code, {{DOMParentNode}} is always created as a concrete instance as a class 
member and never deleted via a pointer, so it's likely unnecessary to make this 
change.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Comment Edited] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047971#comment-16047971
 ] 

Roger Leigh edited comment on XERCESC-2100 at 6/13/17 2:38 PM:
---

The main thing I can see in favour of a non-virtual dtor is not having a vtable 
and saving one vtable-pointer per parent class.  But that may be a premature 
optimisation to make, and I'd personally value correctness and stability over a 
tiny performance gain.


was (Author: rleigh):
The main thing I can see in favour of a non-virtual dtor is not having a vtable 
and saving one pointer per parent class.  But that may be a premature 
optimisation to make, and I'd personally value correctness and stability over a 
tiny performance gain.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2073) autoconf uses incorrect size_t and ssize_t fallback types

2017-06-15 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2073.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

Fixed in 1798795.

> autoconf uses incorrect size_t and ssize_t fallback types
> -
>
> Key: XERCESC-2073
> URL: https://issues.apache.org/jira/browse/XERCESC-2073
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: Using autoconf build
>Reporter: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: autoconf-size-fallbacks.patch
>
>
> size_t is unsigned, ssize_t is signed.  However, the fallback types are 
> swapped making them incorrect for their purpose.  The attached patch 
> rectifies this oversight.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (XERCESC-2103) Remove Win32 projects on the trunk

2017-06-14 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2103:


 Summary: Remove Win32 projects on the trunk
 Key: XERCESC-2103
 URL: https://issues.apache.org/jira/browse/XERCESC-2103
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.2.0
Reporter: Roger Leigh
 Attachments: 0001-projects-Remove-Win32-projects.patch.xz

The attached patch removes all the Win32 project files from the {{projects}} 
directory on the trunk.

- [branch|https://github.com/rleigh-codelibre/xerces-c/commits/remove-projects]
- [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/243056449]
- 
[appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.95]

It also drops the Windows and Borland instructions from the documentation.  
CMake will generate project and solution files for all the removed platforms.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-09 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Attachment: 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch

> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 
> 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - 
> [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your git 
> repo will be automatically built in several configuration combinations for 
> Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
> 2015).  The exact combinations tested are viewable with the above build 
> links, or in the attached patch files.  The set of test combinations can be 
> adjusted as desired.
> This could additionally be enabled for the Apache GitHub mirror or the Apache 
> git repo itself, which would trigger builds for all subversion commits to do 
> post-commit testing.
> Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-09 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Attachment: (was: 0003-ci-Add-travis-support-for-Linux.patch)

> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 
> 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - 
> [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your git 
> repo will be automatically built in several configuration combinations for 
> Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
> 2015).  The exact combinations tested are viewable with the above build 
> links, or in the attached patch files.  The set of test combinations can be 
> adjusted as desired.
> This could additionally be enabled for the Apache GitHub mirror or the Apache 
> git repo itself, which would trigger builds for all subversion commits to do 
> post-commit testing.
> Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-09 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Attachment: (was: 
0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch)

> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 
> 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - 
> [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your git 
> repo will be automatically built in several configuration combinations for 
> Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
> 2015).  The exact combinations tested are viewable with the above build 
> links, or in the attached patch files.  The set of test combinations can be 
> adjusted as desired.
> This could additionally be enabled for the Apache GitHub mirror or the Apache 
> git repo itself, which would trigger builds for all subversion commits to do 
> post-commit testing.
> Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services

2017-06-09 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2098:
-
Description: 
The project does not currently have any continuous integration in place.  I've 
spent the last few days getting a working solution to consider.  The attached 
patch files add support for two commonly used services, 
[Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] 
(Windows).

See this [GitHub 
branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
commit has a green tick mark, which is the CI status.  This links through to 
the build results:

- [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155]
- 
[AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87]

How to use this?  Go to the Travis or AppVeyor websites and log in with 
GitHub/BitBucket/GitLab credentials, or use you own public git repo.  Enable 
the service for your xerces-c git repo.  Now any branch you push to your git 
repo will be automatically built in several configuration combinations for 
Linux (Autotools, CMake), MacOS X (Autotools, CMake)  and Windows (CMake with 
Cygwin, MingGW64 and MSVC 2015).  The exact combinations tested are viewable 
with the above build links, or in the attached patch files.  The set of test 
combinations can be adjusted as desired.  The initial set of combinations 
exercise all configurable options, debug and release builds.

This could additionally be enabled for the Apache GitHub mirror or the Apache 
git repo itself, which would trigger builds for all subversion commits to do 
post-commit testing.

Would there be any objection to committing these changes?

  was:
The project does not currently have any continuous integration in place.  I've 
spent the last few days getting a working solution to consider.  The attached 
patch files add support for two commonly used services, 
[Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] 
(Windows).

See this [GitHub 
branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
commit has a green tick mark, which is the CI status.  This links through to 
the build results:

- 
[Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification]
- 
[AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76]

How to use this?  Go to the Travis or AppVeyor websites and log in with 
GitHub/BitBucket|GitLab credentials, or use you own public git repo.  Enable 
the service for your xerces-c git repo.  Now any branch you push to your git 
repo will be automatically built in several configuration combinations for 
Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 
2015).  The exact combinations tested are viewable with the above build links, 
or in the attached patch files.  The set of test combinations can be adjusted 
as desired.

This could additionally be enabled for the Apache GitHub mirror or the Apache 
git repo itself, which would trigger builds for all subversion commits to do 
post-commit testing.

Would there be any objection to committing these changes?


> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Attachments: 
> 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket/GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your gi

[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms

2017-06-09 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044380#comment-16044380
 ] 

Roger Leigh commented on XERCESC-1785:
--

In the other ticket, I've added MacOS X to the list of test builds.  
Solaris/OpenSolaris doesn't seem to be well supported by these facilities, so I 
can't easily add that at present.

> Build and test on all supported platforms
> -
>
> Key: XERCESC-1785
> URL: https://issues.apache.org/jira/browse/XERCESC-1785
> Project: Xerces-C++
>  Issue Type: Task
>  Components: Build
>Reporter: Boris Kolpackov
>Priority: Blocker
> Fix For: 3.2.0
>
>
> We need to make sure that building, testing and installation work on all 
> platforms that we have committed to support. See the following Wiki page for 
> the status:
> http://wiki.apache.org/xerces/XercescBuildStatus



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-11 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2100:
-
Description: 
These patches have been sitting around for nearly a year, but I've rebased them 
onto the trunk and tested them again.  They cover several classes of fix:

- minor build improvements
- minor tweaks to feature tests
- enabling stricter compiler warnings, and then fixing those warnings
- fixing mismatched delete/delete[] (bad)
- adding missing virtual destructors (bad)
- removing unused variables
- removing unused variables conditionally when used conditionally
- removing cast warnings with appropriate C++ const/static/reinterpret casts

Most of the fixes are tiny one-liners to fix warnings.
Builds:

- [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
- 
[appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]

  was:
These patches have been sitting around for nearly a year, but I've rebased them 
onto the trunk and tested them again.

Builds:

- https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965


> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-11 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2100:


 Summary: [patch] Small fixes for warnings and errors
 Key: XERCESC-2100
 URL: https://issues.apache.org/jira/browse/XERCESC-2100
 Project: Xerces-C++
  Issue Type: Bug
Affects Versions: 3.2.0
Reporter: Roger Leigh
 Attachments: 
0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
0002-cmake-Debug-FindThreads.patch, 
0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
0005-cmake-Enable-extra-compiler-warnings.patch, 
0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
0017-xercesc-XMLUri-Remove-unused-variables.patch, 
0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
0020-tests-DTest-Remove-unused-variables.patch, 
0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
0022-tests-XSTSHarness-Remove-unused-variables.patch, 
0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
0026-xercesc-QName-Add-mising-const_casts.patch, 
0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch

These patches have been sitting around for nearly a year, but I've rebased them 
onto the trunk and tested them again.

Builds:

- https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0001-cmake-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Priority: Minor
> Attachments: char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch
0002-cmake-Check-for-char16_t.patch
0003-autoconf-Check-for-char16_t.patch

Update patches; now works with cmake and autoconf on Unix and Windows.

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Priority: Minor
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, 
> char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Issue Comment Deleted] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Comment: was deleted

(was: I've tried your patch on the trunk with my cmake support (patch 
attached).  Unfortunately it's failing here:

{noformat}
[266/343] Building CXX object 
src\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj
FAILED: 
src/CMakeFiles/xerces-c.dir/xercesc/util/Transcoders/Win32/Win32TransService.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe  /nologo /TP -DHAVE_CONFIG_H 
-DXERCES_BUILDING_LIBRARY -DXERCES_DLL_NAME=\"xerces-c_3_1d.dll\0\" 
-Dxerces_c_EXPORTS -I. -IH:\xerces-c\src -Isrc /DWIN32 /D_WINDOWS /W3 /GR /EHsc 
/MDd /Zi /Ob0 /Od /RTC1 /showIncludes 
/Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj
 /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp
H:\xerces-c\src\xercesc/util/TransService.hpp(559): warning C4251: 
'xercesc_3_1::TranscodeToStr::fString': class 
'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by 
clients of class 'xercesc_3_1::TranscodeToStr'
H:\xerces-c\src\xercesc/util/TransService.hpp(559): note: see declaration of 
'xercesc_3_1::ArrayJanitor'
H:\xerces-c\src\xercesc/util/TransService.hpp(641): warning C4251: 
'xercesc_3_1::TranscodeFromStr::fString': class 
'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by 
clients of class 'xercesc_3_1::TranscodeFromStr'
H:\xerces-c\src\xercesc/util/TransService.hpp(641): note: see declaration of 
'xercesc_3_1::ArrayJanitor'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(333): 
warning C4996: 'GetVersionExA': was declared deprecated
C:\Program Files (x86)\Windows Kits\8.1\include\um\sysinfoapi.h(433): note: see 
declaration of 'GetVersionExA'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): 
error C2664: 'int _wcsicmp(const wchar_t *,const wchar_t *)': cannot convert 
argument 1 from 'const XMLCh *const ' to 'const wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): 
error C2664: 'int _wcsnicmp(const wchar_t *,const wchar_t *,std::size_t)': 
cannot convert argument 1 from 'const XMLCh *const ' to 'const wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *const ' to 'wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): 
error C2664: 'wchar_t *_wcslwr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *const ' to 'wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\s

[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0002-autoconf-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Priority: Minor
> Attachments: char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049226#comment-16049226
 ] 

Roger Leigh commented on XERCESC-2101:
--

- [Unix build 
results|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/242814234]
- [Windows build 
results|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.92]

All builds have passed using a mixture of old and new compilers using the 
previous defaults and char16_t, respectively.

Overall, this is a fairly trivial change to a typedef with the changes to the 
supporting build infrastructure to detect and enable it.  It enables the use of 
{{u"Unicode string"}}, which offers a significant usability improvement for end 
users of the library API, as well as a potential minor performance improvement 
by removing the need to transcode from 8-bit strings.  No need to transcode to 
wide strings for every element and attribute name, it's all handled at compile 
time by the compiler.



> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Priority: Minor
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, 
> char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-14 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049702#comment-16049702
 ] 

Roger Leigh commented on XERCESC-2100:
--

I've committed these minus the virtual dtor patches (12 and 13).  I've also 
removed the extra compiler warning for non-virtual-dtors.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2100.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

Committed all patches with the exceptions of 12 and 13.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2098) Add support for external continuous integration services

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2098.
--
   Resolution: Fixed
Fix Version/s: 3.2.0

SVN revisions 1798779 and 1798780.

> Add support for external continuous integration services
> 
>
> Key: XERCESC-2098
> URL: https://issues.apache.org/jira/browse/XERCESC-2098
> Project: Xerces-C++
>  Issue Type: Test
>  Components: Miscellaneous
>Affects Versions: 3.2.0
> Environment: Unix/Linux
> Windows (MSVC, Cygwin, MinGW)
>Reporter: Roger Leigh
>  Labels: appveyor, continuous_integration, travis-ci
> Fix For: 3.2.0
>
> Attachments: 
> 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 
> 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch
>
>
> The project does not currently have any continuous integration in place.  
> I've spent the last few days getting a working solution to consider.  The 
> attached patch files add support for two commonly used services, 
> [Travis|https://travis-ci.org/] (Unix) and 
> [AppVeyor|https://www.appveyor.com] (Windows).
> See this [GitHub 
> branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci].  The last 
> commit has a green tick mark, which is the CI status.  This links through to 
> the build results:
> - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155]
> - 
> [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87]
> How to use this?  Go to the Travis or AppVeyor websites and log in with 
> GitHub/BitBucket/GitLab credentials, or use you own public git repo.  Enable 
> the service for your xerces-c git repo.  Now any branch you push to your git 
> repo will be automatically built in several configuration combinations for 
> Linux (Autotools, CMake), MacOS X (Autotools, CMake)  and Windows (CMake with 
> Cygwin, MingGW64 and MSVC 2015).  The exact combinations tested are viewable 
> with the above build links, or in the attached patch files.  The set of test 
> combinations can be adjusted as desired.  The initial set of combinations 
> exercise all configurable options, debug and release builds.
> This could additionally be enabled for the Apache GitHub mirror or the Apache 
> git repo itself, which would trigger builds for all subversion commits to do 
> post-commit testing.
> Would there be any objection to committing these changes?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (XERCESC-2102) Documentation is not generatable on moderns systems

2017-06-14 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2102:


 Summary: Documentation is not generatable on moderns systems
 Key: XERCESC-2102
 URL: https://issues.apache.org/jira/browse/XERCESC-2102
 Project: Xerces-C++
  Issue Type: Bug
  Components: Documentation
Reporter: Roger Leigh


The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}.  
Unfortunately this tool appears to no longer be developed and it no longer 
works with contemporary JREs due to relying upon 
{com.sun.image.codec.jpeg.JPEGCodec} which is no longer present.  It's 
achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming 
increasingly difficult to make work.

Was there ever a migration path from slidebook to any other format which is 
currently supported?

Would there be any interest in moving to a contemporary documentation format, 
and if so are there any preferred formats?  At work we use Sphinx.  I'd be 
happy to spend a few hours converting it to this or some other format which is 
currently supported.

Regards,
Roger

{noformat}
% make createdocs   
[StyleBook] Overriding 
targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".")
[StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml"
[BasicEngine] Initializing
[Loader] Parsing Project file
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl"
[XalanProcessor] Applying XSL sheet 
"sbk:/style/stylesheets/directory2project.xsl"
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (1)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (2)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (3)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (4)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (5)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (6)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (7)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (8)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (9)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (10)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (11)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (12)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (13)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (14)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (15)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (16)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (17)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
[CachingParser] Serving cached document 
"sbk:/style/stylesheets/any2project.xsl" (18)
[XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2p

[jira] [Updated] (XERCESC-2102) Documentation is not generatable on modern systems

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2102:
-
Summary: Documentation is not generatable on modern systems  (was: 
Documentation is not generatable on moderns systems)

> Documentation is not generatable on modern systems
> --
>
> Key: XERCESC-2102
> URL: https://issues.apache.org/jira/browse/XERCESC-2102
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>    Reporter: Roger Leigh
>
> The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}.  
> Unfortunately this tool appears to no longer be developed and it no longer 
> works with contemporary JREs due to relying upon 
> {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present.  It's 
> achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming 
> increasingly difficult to make work.
> Was there ever a migration path from slidebook to any other format which is 
> currently supported?
> Would there be any interest in moving to a contemporary documentation format, 
> and if so are there any preferred formats?  At work we use Sphinx.  I'd be 
> happy to spend a few hours converting it to this or some other format which 
> is currently supported.
> Regards,
> Roger
> {noformat}
> % make createdocs   
> [StyleBook] Overriding 
> targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".")
> [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml"
> [BasicEngine] Initializing
> [Loader] Parsing Project file
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl"
> [XalanProcessor] Applying XSL sheet 
> "sbk:/style/stylesheets/directory2project.xsl"
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (1)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (2)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (3)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (4)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (5)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (6)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (7)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (8)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (9)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (10)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (11)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (12)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (13)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (14)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/s

[jira] [Commented] (XERCESC-2073) autoconf uses incorrect size_t and ssize_t fallback types

2017-06-14 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049804#comment-16049804
 ] 

Roger Leigh commented on XERCESC-2073:
--

- 
[branch|https://github.com/rleigh-codelibre/xerces-c/commits/autoconf-size-fallbacks]
- [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/243028832]
- 
[appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.94]

> autoconf uses incorrect size_t and ssize_t fallback types
> -
>
> Key: XERCESC-2073
> URL: https://issues.apache.org/jira/browse/XERCESC-2073
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: Using autoconf build
>Reporter: Roger Leigh
>Priority: Minor
> Attachments: autoconf-size-fallbacks.patch
>
>
> size_t is unsigned, ssize_t is signed.  However, the fallback types are 
> swapped making them incorrect for their purpose.  The attached patch 
> rectifies this oversight.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048915#comment-16048915
 ] 

Roger Leigh commented on XERCESC-2101:
--

I've tried your patch on the trunk with my cmake support (patch attached).  
Unfortunately it's failing here:

{noformat}
[266/343] Building CXX object 
src\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj
FAILED: 
src/CMakeFiles/xerces-c.dir/xercesc/util/Transcoders/Win32/Win32TransService.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe  /nologo /TP -DHAVE_CONFIG_H 
-DXERCES_BUILDING_LIBRARY -DXERCES_DLL_NAME=\"xerces-c_3_1d.dll\0\" 
-Dxerces_c_EXPORTS -I. -IH:\xerces-c\src -Isrc /DWIN32 /D_WINDOWS /W3 /GR /EHsc 
/MDd /Zi /Ob0 /Od /RTC1 /showIncludes 
/Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj
 /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c 
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp
H:\xerces-c\src\xercesc/util/TransService.hpp(559): warning C4251: 
'xercesc_3_1::TranscodeToStr::fString': class 
'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by 
clients of class 'xercesc_3_1::TranscodeToStr'
H:\xerces-c\src\xercesc/util/TransService.hpp(559): note: see declaration of 
'xercesc_3_1::ArrayJanitor'
H:\xerces-c\src\xercesc/util/TransService.hpp(641): warning C4251: 
'xercesc_3_1::TranscodeFromStr::fString': class 
'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by 
clients of class 'xercesc_3_1::TranscodeFromStr'
H:\xerces-c\src\xercesc/util/TransService.hpp(641): note: see declaration of 
'xercesc_3_1::ArrayJanitor'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *' to 'wchar_t
*'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(333): 
warning C4996: 'GetVersionExA': was declared deprecated
C:\Program Files (x86)\Windows Kits\8.1\include\um\sysinfoapi.h(433): note: see 
declaration of 'GetVersionExA'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): 
error C2664: 'int _wcsicmp(const wchar_t *,const wchar_t *)': cannot convert 
argument 1 from 'const XMLCh *const ' to 'const wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): 
error C2664: 'int _wcsnicmp(const wchar_t *,const wchar_t *,std::size_t)': 
cannot convert argument 1 from 'const XMLCh *const ' to 'const wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): 
error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *const ' to 'wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): 
error C2664: 'wchar_t *_wcslwr(wchar_t *)': cannot convert argument 1 from 
'XMLCh *const ' to 'wchar_t *'
H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): 
note: Types pointed to are unrelated; conversion requires reinterpret_cast, 
C-style cast or function-style cast
H:\xe

[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t

2017-06-14 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2101:
-
Attachment: 0001-cmake-Check-for-char16_t.patch
0002-autoconf-Check-for-char16_t.patch

Add cmake and autoconf support for char16_t

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Priority: Minor
> Attachments: 0001-cmake-Check-for-char16_t.patch, 
> 0002-autoconf-Check-for-char16_t.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Comment Edited] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048004#comment-16048004
 ] 

Roger Leigh edited comment on XERCESC-2100 at 6/13/17 3:21 PM:
---

For me, mainly for robustness in the face of future changes or refactoring.  
Right now it's not needed, of course, but it could avoid introducing buggy 
behaviour down the line, so is primarily defensive.  I'm happy to omit it if 
it's not wanted.


was (Author: rleigh):
For me, mainly for robustness in the face of future changes or refactoring.  
Right now it's not needed, of course, but it could avoid introducing buggy 
behaviour down the line, so is primarily defensive.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors

2017-06-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048004#comment-16048004
 ] 

Roger Leigh commented on XERCESC-2100:
--

For me, mainly for robustness in the face of future changes or refactoring.  
Right now it's not needed, of course, but it could avoid introducing buggy 
behaviour down the line, so is primarily defensive.

> [patch] Small fixes for warnings and errors
> ---
>
> Key: XERCESC-2100
> URL: https://issues.apache.org/jira/browse/XERCESC-2100
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>  Labels: patch
> Attachments: 
> 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 
> 0002-cmake-Debug-FindThreads.patch, 
> 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 
> 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 
> 0005-cmake-Enable-extra-compiler-warnings.patch, 
> 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 
> 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 
> 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 
> 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 
> 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 
> 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 
> 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 
> 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 
> 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 
> 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 
> 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 
> 0017-xercesc-XMLUri-Remove-unused-variables.patch, 
> 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 
> 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 
> 0020-tests-DTest-Remove-unused-variables.patch, 
> 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 
> 0022-tests-XSTSHarness-Remove-unused-variables.patch, 
> 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 
> 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 
> 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 
> 0026-xercesc-QName-Add-mising-const_casts.patch, 
> 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 
> 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 
> 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 
> 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 
> 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 
> 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 
> 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 
> 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 
> 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch
>
>
> These patches have been sitting around for nearly a year, but I've rebased 
> them onto the trunk and tested them again.  They cover several classes of fix:
> - minor build improvements
> - minor tweaks to feature tests
> - enabling stricter compiler warnings, and then fixing those warnings
> - fixing mismatched delete/delete[] (bad)
> - adding missing virtual destructors (bad)
> - removing unused variables
> - removing unused variables conditionally when used conditionally
> - removing cast warnings with appropriate C++ const/static/reinterpret casts
> Most of the fixes are tiny one-liners to fix warnings.
> Builds:
> - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965]
> - 
> [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2121) xercesc-3.2.0 fails to configure with cmake, gnuiconv on Solaris.

2017-09-29 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186371#comment-16186371
 ] 

Roger Leigh commented on XERCESC-2121:
--

Thanks for picking this up.  I'm not sure how those typos ended up there; maybe 
a regex without a trailing {g}.

> xercesc-3.2.0 fails to configure with cmake, gnuiconv on Solaris.
> -
>
> Key: XERCESC-2121
> URL: https://issues.apache.org/jira/browse/XERCESC-2121
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Solaris, gnuiconv present and selected with 
> -Dtranscoder=gnuiconv
>Reporter: Fj
>Priority: Minor
> Attachments: xercesc.patch
>
>
> Looks like a simple typo: variable names should use underscores instead of 
> slashes. This patch fixes it:
> {code}
> --- xerces-c-3.2.0/cmake/XercesTranscoderSelection.cmake.orig   2017-09-22 
> 17:15:15.892155444 +0300
> +++ xerces-c-3.2.0/cmake/XercesTranscoderSelection.cmake2017-09-22 
> 17:18:21.663148228 +0300
> @@ -59,7 +59,7 @@
>  set(gnuiconv_available 0)
>  if(HAVE_ICONV_H AND HAVE_WCHAR_H AND HAVE_STRING_H AND HAVE_STDLIB_H AND
>  HAVE_STDIO_H AND HAVE_CTYPE_H AND HAVE_LOCALE_H AND HAVE_ERRNO_H)
> -  if (HAVE_ENDIAN_H OR HAVE_MACHINE/ENDIAN_H OR HAVE_ARPA/NAMESER_COMPAT_H)
> +  if (HAVE_ENDIAN_H OR HAVE_MACHINE_ENDIAN_H OR HAVE_ARPA_NAMESER_COMPAT_H)
>  if(HAVE_ICONV_OPEN AND HAVE_ICONV_CLOSE AND HAVE_ICONV)
>set(gnuiconv_available 1)
>list(APPEND transcoders gnuiconv)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2114) Link failure with Xalan-C

2017-09-29 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186278#comment-16186278
 ] 

Roger Leigh commented on XERCESC-2114:
--

[~mat] That's very interesting.  If you have a chance to retry building 3.1 
with VS vs 3.2 with CMake I'd be very interested what the compiler flag 
discrepancy might be, so we can add back the missing flag (or remove the extra 
flag etc.).

> Link failure with Xalan-C
> -
>
> Key: XERCESC-2114
> URL: https://issues.apache.org/jira/browse/XERCESC-2114
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: VS2013 on Windows Server 2012R2
>Reporter: Roger Leigh
>
> Testing latest rc1 with xalan and VS2013:
> [Build 
> log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]
> Using [this 
> patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
>  to build Xalan with VS2013 (it's just the upgraded project files).
> {noformat}
> 12:29:32(Link target) -> 
> 12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: 
> unresolved external symbol "__declspec(dllimport) unsigned __int64 const 
> `public: static unsigned __int64 __cdecl 
> xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
> __int64)'::`2'::alignment" 
> (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
>  
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> 12:29:32  ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : 
> fatal error LNK1120: 1 unresolved externals 
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> {noformat}
> Is there any incompatible change expected here?  Could potentially be missing 
> symbol exports or anything of that nature?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2125) CMake variable for nothreads does not match generated config define

2018-01-05 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312925#comment-16312925
 ] 

Roger Leigh commented on XERCESC-2125:
--

Interestingly, after fixing the variable name this shows up a possible flaw in 
the autoconf/make build.  If you disable threads, it's still linking everything 
with pthreads, including the thread tests, so it's not really "nothread" at 
all!  This includes all the thread tests.

> CMake variable for nothreads does not match generated config define
> ---
>
> Key: XERCESC-2125
> URL: https://issues.apache.org/jira/browse/XERCESC-2125
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows 8.1 64 bit, Visual Studio 2015, CMake 3.9.1
>Reporter: Sam Vanheer
>
> When the mutex manager is set to nothreads, the generated config will not 
> enable the XERCES_USE_MUTEXMGR_NOTHREAD definition.
> This is because the configure_file function takes CMake variable names to use 
> for #cmakedefine, but the name for that configuration is 
> XERCES_USE_MUTEXMGR_NOTHREADS, defined in cmake/XercesMutexMgrSelection.cmake.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2125) CMake variable for nothreads does not match generated config define

2018-01-05 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2125.
--
   Resolution: Fixed
 Assignee: Roger Leigh
Fix Version/s: 3.2.1

Fixed in SVN commits 1820309 and 1820311.

While the autoconf/make logic is building the ThreadTests for some reason even 
with threading explicitly disabled (it appears libtool is automatically using 
{{-pthread}}), for CMake we need to disable the ThreadTests when threading is 
disabled since it requires pthreads, which are intentionally missing in this 
situation.

> CMake variable for nothreads does not match generated config define
> ---
>
> Key: XERCESC-2125
> URL: https://issues.apache.org/jira/browse/XERCESC-2125
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: Windows 8.1 64 bit, Visual Studio 2015, CMake 3.9.1
>Reporter: Sam Vanheer
>Assignee: Roger Leigh
> Fix For: 3.2.1
>
>
> When the mutex manager is set to nothreads, the generated config will not 
> enable the XERCES_USE_MUTEXMGR_NOTHREAD definition.
> This is because the configure_file function takes CMake variable names to use 
> for #cmakedefine, but the name for that configuration is 
> XERCES_USE_MUTEXMGR_NOTHREADS, defined in cmake/XercesMutexMgrSelection.cmake.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (XERCESC-2119) warning C4251: 'xercesc_3_2::TranscodeToStr::fString': class 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used by clients of class 'xercesc_3

2018-01-04 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2119.
--
   Resolution: Fixed
 Assignee: Roger Leigh
Fix Version/s: 3.2.1

Fix committed in SVN commit 1820126.

I've tested with VS2017 x64 on Windows 10 with and without the change, as well 
as with GCC 7.2 on Linux.  Tests pass in all cases on both.

> warning C4251: 'xercesc_3_2::TranscodeToStr::fString': class 
> 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used 
> by clients of class 'xercesc_3_2::TranscodeToStr'
> --
>
> Key: XERCESC-2119
> URL: https://issues.apache.org/jira/browse/XERCESC-2119
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.2.0
> Environment: windows
>Reporter: Mathieu Champlon
>Assignee: Roger Leigh
> Fix For: 3.2.1
>
> Attachments: dll_interface.patch
>
>
> Upgrading from xerces 3.1.2 to 3.2.0 on windows introduces a few of
> {noformat}
> (...)\include\xercesc/util/TransService.hpp(559): error C2220: warning 
> treated as error - no 'object' file generated
> (...)\include\xercesc/util/TransService.hpp(559): warning C4251: 
> 'xercesc_3_2::TranscodeToStr::fString': class 
> 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used 
> by clients of class 'xercesc_3_2::TranscodeToStr'
> (...)\include\xercesc/util/TransService.hpp(559): note: see declaration of 
> 'xercesc_3_2::ArrayJanitor'
> (...)\include\xercesc/util/TransService.hpp(641): warning C4251: 
> 'xercesc_3_2::TranscodeFromStr::fString': class 
> 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used by 
> clients of class 'xercesc_3_2::TranscodeFromStr'
> (...)\include\xercesc/util/TransService.hpp(641): note: see declaration of 
> 'xercesc_3_2::ArrayJanitor'
> {noformat}
> As pragma deactivating C4251 is frown upon on the project I work, I ended up 
> exporting the types, see attached patch.
> Note that this was also mentioned in XERCESC-1974.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)

2018-01-22 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334086#comment-16334086
 ] 

Roger Leigh commented on XERCESC-2130:
--

I'm not a legal expert, and I don't know where the Apache organisation draws 
the line between trivial and non-trivial contributions which require a CLA, but 
I suspect this counts as non-trivial.  I think you would need to fill out an 
[individual CLA]([https://www.apache.org/licenses/#clas)] to allow this to be 
included.  However, others might wish to correct me if I'm wrong.

> UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 
> 3.2.0 (e.g. emoticons)
> 
>
> Key: XERCESC-2130
> URL: https://issues.apache.org/jira/browse/XERCESC-2130
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.0
>Reporter: Andreas Krantz
>Priority: Critical
> Attachments: fix.patch, patch_.cpp, reproduce.cpp
>
>
> Solution for XERCESC-1854 introduced method
> {{DOMLSSerializerImpl::ensureValidString}}
> which has an error in validation. 
> The method validates XMLCh which represent UTF16.
> [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | 
> [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
> are the valid UTF32 characters.
> The UTF16 surrogate range from xD800 - xDFFF is used to represent 
> [#x1-#x10] and should not be handled as nvalid.
> *The reader threads this correctly and does not complain, which leads to an 
> asmetric behavior*
> Reading DOM => OK
> Save back DOM => Exception
> I tried to attach an example to show the behavior.
> The used methods
> {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}}
> already have a second optional parameter to check surrogate values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)

2018-01-22 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334103#comment-16334103
 ] 

Roger Leigh commented on XERCESC-2130:
--

Regarding signing, I did my work on my employer's time for at least some of it, 
so I had to get them to also sign a corporate CLA.  It wasn't a problem, but it 
was a massive pain due to it taking about six months to be approved.  May be 
easier for smaller organisations with less tortuous bureaucracy!

> UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 
> 3.2.0 (e.g. emoticons)
> 
>
> Key: XERCESC-2130
> URL: https://issues.apache.org/jira/browse/XERCESC-2130
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.0
>Reporter: Andreas Krantz
>Priority: Critical
> Attachments: fix.patch, patch_.cpp, reproduce.cpp
>
>
> Solution for XERCESC-1854 introduced method
> {{DOMLSSerializerImpl::ensureValidString}}
> which has an error in validation. 
> The method validates XMLCh which represent UTF16.
> [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | 
> [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
> are the valid UTF32 characters.
> The UTF16 surrogate range from xD800 - xDFFF is used to represent 
> [#x1-#x10] and should not be handled as nvalid.
> *The reader threads this correctly and does not complain, which leads to an 
> asmetric behavior*
> Reading DOM => OK
> Save back DOM => Exception
> I tried to attach an example to show the behavior.
> The used methods
> {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}}
> already have a second optional parameter to check surrogate values.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)

2018-01-12 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323829#comment-16323829
 ] 

Roger Leigh commented on XERCESC-2130:
--

Ouch, emoticons were a bit of a low blow!

I'm not sure what the threshold is for contributions to require it, but have 
you already submitted the Apache CLA?

Thanks,
Roger

> UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 
> 3.2.0 (e.g. emoticons)
> 
>
> Key: XERCESC-2130
> URL: https://issues.apache.org/jira/browse/XERCESC-2130
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.0
>Reporter: Andreas Krantz
>Priority: Critical
> Attachments: fix.patch, patch_.cpp, reproduce.cpp
>
>
> Solution for XERCESC-1854 introduced method
> {{DOMLSSerializerImpl::ensureValidString}}
> which has an error in validation. 
> The method validates XMLCh which represent UTF16.
> [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | 
> [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
> are the valid UTF32 characters.
> The UTF16 surrogate range from xD800 - xDFFF is used to represent 
> [#x1-#x10] and should not be handled as nvalid.
> *The reader threads this correctly and does not complain, which leads to an 
> asmetric behavior*
> Reading DOM => OK
> Save back DOM => Exception
> I tried to attach an example to show the behavior.
> The used methods
> {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}}
> already have a second optional parameter to check surrogate values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (XERCESC-2134) CMake build missing support for Win32MsgLoader

2018-01-30 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2134:


 Summary: CMake build missing support for Win32MsgLoader
 Key: XERCESC-2134
 URL: https://issues.apache.org/jira/browse/XERCESC-2134
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build
Affects Versions: 3.2.0
Reporter: Roger Leigh
Assignee: Roger Leigh


The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
copied from, so all Windows builds are currently defaulting to the 
InMemoryMsgLoader.  This is an unintentional omission which is simple to 
correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (XERCESC-2134) Remove non-functional Win32MsgLoader code

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2134:
-
Summary: Remove non-functional Win32MsgLoader code  (was: CMake build 
missing support for Win32MsgLoader)

> Remove non-functional Win32MsgLoader code
> -
>
> Key: XERCESC-2134
> URL: https://issues.apache.org/jira/browse/XERCESC-2134
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>
> The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
> copied from, so all Windows builds are currently defaulting to the 
> InMemoryMsgLoader.  This is an unintentional omission which is simple to 
> correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2134) CMake build missing support for Win32MsgLoader

2018-01-30 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345346#comment-16345346
 ] 

Roger Leigh commented on XERCESC-2134:
--

Looking more closely, the Windows builds in 3.1 were already using the InMemory 
message loader, so there weren't any users of this code.  Looking more closely 
at it:

 

   static const char* const privDLLName = "IXUTIL"; 
    fModHandle = ::GetModuleHandleA(privDLLName);

 

it looks like this code wouldn't be functional in any case (there's no IXUTIL 
module, and it's not clear where the resources it would load come from–there's 
no remaining logic to generate them).

 

Would anyone object to this old, unused and non-functional code being removed 
from the source repository?

> CMake build missing support for Win32MsgLoader
> --
>
> Key: XERCESC-2134
> URL: https://issues.apache.org/jira/browse/XERCESC-2134
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>
> The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
> copied from, so all Windows builds are currently defaulting to the 
> InMemoryMsgLoader.  This is an unintentional omission which is simple to 
> correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (XERCESC-2134) Remove non-functional Win32MsgLoader code

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2134:
-
Attachment: 0001-Remove-unused-and-broken-Win32MsgLoader.patch

> Remove non-functional Win32MsgLoader code
> -
>
> Key: XERCESC-2134
> URL: https://issues.apache.org/jira/browse/XERCESC-2134
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Attachments: 0001-Remove-unused-and-broken-Win32MsgLoader.patch
>
>
> The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
> copied from, so all Windows builds are currently defaulting to the 
> InMemoryMsgLoader.  This is an unintentional omission which is simple to 
> correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-1942) Xerces64 bit build with ICU3.6 64 bit does not Support encodings

2018-01-30 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345792#comment-16345792
 ] 

Roger Leigh commented on XERCESC-1942:
--

[~dineshkumar] Is this still an issue with current Xerces 3.2.0 and a current 
ICU release?

> Xerces64 bit build with ICU3.6 64 bit does not Support encodings
> 
>
> Key: XERCESC-1942
> URL: https://issues.apache.org/jira/browse/XERCESC-1942
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Samples/Tests
>Affects Versions: 3.1.1
>Reporter: dinesh kumar
>Priority: Major
>
> I built 64 bit Xerces 3.1 with ICU 3.6 with VIsual Studio 2008 on windows 
> 2008.  I am able to compile the code completely after changing the Project 
> settings of ICU and used Win64 preprocessor in C/C++ preprocessor settings.  
> Attempt to test the build if xerces supports Big5 encoding and other encoding 
> seems to fail. 
> I tested with SAX2print.exe sample to convert to a particular Big5 encoding 
> and it says , unable to create converter for Big5.
> Tested 64 bit Xerces 3.1 build with ICu 4.0 with visual studio 2008 also 
> fails with the test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (XERCESC-2132) cmake: Add the ability to force the specific XMLCh type to use

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2132.
--
   Resolution: Fixed
Fix Version/s: 3.2.1

Fixed in SVN commits 1822689-93.

 

[~akrantz] The reinterpret_cast fixes are now in place as well.  If you would 
like to re-test, it should build without problems for all possible (valid) 
configurations now.

> cmake: Add the ability to force the specific XMLCh type to use
> --
>
> Key: XERCESC-2132
> URL: https://issues.apache.org/jira/browse/XERCESC-2132
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
>
> Currently the CMake build default to a 16-bit integer type.  It will use 
> char16_t where available, and fall back to wchar_t on Windows when available. 
>  This means that old Visual Studio versions will use wchar_t while newer ones 
> use char16_t, but there are cases where selection of a specific XMLCh type is 
> desirable, to force the use of wchar_t e.g. for compatibility reasons.
>  
> Add an option to select a specific XMLCh type, overriding the default checks 
> and fallbacks.
>  
> Also, check that the autotools build behaves the same way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (XERCESC-2134) Remove non-functional Win32MsgLoader code

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2134:
-
Flags: Patch

> Remove non-functional Win32MsgLoader code
> -
>
> Key: XERCESC-2134
> URL: https://issues.apache.org/jira/browse/XERCESC-2134
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Attachments: 0001-Remove-unused-and-broken-Win32MsgLoader.patch
>
>
> The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
> copied from, so all Windows builds are currently defaulting to the 
> InMemoryMsgLoader.  This is an unintentional omission which is simple to 
> correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (XERCESC-1609) Ported Xerces-C++ to Windows Mobile

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-1609.
--
   Resolution: Won't Fix
Fix Version/s: 3.2.0

With Xerces-C++ 3.2.0, all the separate solution files were removed and 
replaced with a unified CMake build which can target arbitrary toolchains, and 
this includes WinCE and others.  This should be an adequate replacement.

> Ported Xerces-C++ to Windows Mobile
> ---
>
> Key: XERCESC-1609
> URL: https://issues.apache.org/jira/browse/XERCESC-1609
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: Nightly build (please specify the date)
> Environment: Build Environment:
>  Visual Studio 2005 Professional Edition.
>  Windows Mobile 5.0 SDK for Pocket PC.
> Test Environment:
>  Emulator
>  Dell Axim X51v
>Reporter: Jin Adachi
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: wince_project.diff, wince_src.diff
>
>
> I ported Xerces-C++ 3.0 to Windows Mobile 5.0 for Pocket PC.
> - Created Windows Mobile 5.0 Pocket PC SDK (ARMV4I) Projects.
> - Ported XercesLib.
> - Ported some samples. (changed entry point, string)
> Restrictions
> - Doesn't work xml4com.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (XERCESC-2135) build: GNU iconv transcoder only works on GNU/Linux

2018-01-30 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2135:


 Summary: build: GNU iconv transcoder only works on GNU/Linux
 Key: XERCESC-2135
 URL: https://issues.apache.org/jira/browse/XERCESC-2135
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build
Reporter: Roger Leigh
Assignee: Roger Leigh


iconv is built into GNU libc, so is linked with automatically.  On non-GNU 
systems, it's a standalone library, which we don't link with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Closed] (XERCESC-2114) Link failure with Xalan-C

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh closed XERCESC-2114.

Resolution: Invalid
  Assignee: Roger Leigh

I couldn't reproduce this with 3.2.0, so closing for now.

> Link failure with Xalan-C
> -
>
> Key: XERCESC-2114
> URL: https://issues.apache.org/jira/browse/XERCESC-2114
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: VS2013 on Windows Server 2012R2
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>
> Testing latest rc1 with xalan and VS2013:
> [Build 
> log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]
> Using [this 
> patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
>  to build Xalan with VS2013 (it's just the upgraded project files).
> {noformat}
> 12:29:32(Link target) -> 
> 12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: 
> unresolved external symbol "__declspec(dllimport) unsigned __int64 const 
> `public: static unsigned __int64 __cdecl 
> xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
> __int64)'::`2'::alignment" 
> (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
>  
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> 12:29:32  ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : 
> fatal error LNK1120: 1 unresolved externals 
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> {noformat}
> Is there any incompatible change expected here?  Could potentially be missing 
> symbol exports or anything of that nature?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Closed] (XERCESC-1976) SIGSEGV during init on SUSE11 when LANG is unset

2018-01-30 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh closed XERCESC-1976.

Resolution: Cannot Reproduce

This seems to be a historical implementation bug in GNU iconv.  Current 
versions of GNU iconv don't exhibit the bug, and as such there's nothing to fix 
or work around in Xerces-C++ at this time.

 

I've tested with current trunk with GNU libc 2.26 (Ubuntu 17.10) and GNU iconv 
2.0 (FreeBSD 11).  I've tested with and without LC*/LANG/LANGUAGE set.  In all 
cases this works correctly as as far as I can tell.

> SIGSEGV during init on SUSE11 when LANG is unset
> 
>
> Key: XERCESC-1976
> URL: https://issues.apache.org/jira/browse/XERCESC-1976
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.1.1
> Environment: SUSE11
>Reporter: Uri Moszkowicz
>Priority: Major
>
> 1. Unset LANG variable
> 2. Run executable using Xerces.
> 3. Crash with the following stack:
>   #36 0x010422f8 in __gconv ()
>   #37 0x0104199b in iconv ()
>   #38 0x00f25bef in 
> xercesc_3_1::IconvGNULCPTranscoder::calcRequiredSize (this=0x4c4cab0, 
> srcText=Variable "srcText" is not available.
>   ) at xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:401
>   #39 0x00f23dcb in xercesc_3_1::IconvGNULCPTranscoder::transcode 
> (this=0x4c4cab0, toTranscode=0x4c8a7d8, manager=0x4c38e98) at 
> xercesc/util/Transcoders/IconvGNU/IconvGNUTransService.cpp:747
>   #40 0x00e6b98f in xercesc_3_1::XMLString::parseInt 
> (toConvert=Variable "toConvert" is not available.
>   ) at xercesc/util/XMLString.cpp:1457
>   #41 0x00f8066d in xercesc_3_1::AbstractStringValidator::assignFacet 
> (this=0x4c8a700, manager=0x4c38e98) at 
> xercesc/validators/datatype/AbstractStringValidator.cpp:152
>   #42 0x00f80a52 in xercesc_3_1::AbstractStringValidator::init 
> (this=0x4c8a700, enums=Variable "enums" is not available.
>   ) at xercesc/validators/datatype/AbstractStringValidator.cpp:100
>   #43 0x00edcd07 in ListDatatypeValidator (this=0x4c8a700, 
> baseValidator=0x4c8a070, facets=Variable "facets" is not available.
>   ) at xercesc/validators/datatype/ListDatatypeValidator.cpp:61
>   #44 0x00ed019b in 
> xercesc_3_1::DatatypeValidatorFactory::createDatatypeValidator (this=Variable 
> "this" is not available.
>   ) at xercesc/validators/datatype/DatatypeValidatorFactory.cpp:643
>   #45 0x00ed3b26 in 
> xercesc_3_1::DatatypeValidatorFactory::expandRegistryToFullSchemaSet 
> (this=0x4c87af0) at 
> xercesc/validators/datatype/DatatypeValidatorFactory.cpp:312
>   #46 0x00ed5ac0 in 
> xercesc_3_1::XMLInitializer::initializeDatatypeValidatorFactory () at 
> xercesc/validators/datatype/DatatypeValidatorFactory.cpp:135
>   #47 0x00e69415 in xercesc_3_1::XMLInitializer::initializeStaticData 
> () at xercesc/util/XMLInitializer.cpp:61
>   #48 0x0068571b in main (argc=23, argv=0x7fff3a9175e8, 
> env=0x7fff3a9176a8) at Main.cc:100
> This is from the first line of the program, which calls 
> XMLPlatformUtils::Initialize() so simply try this program:
> int main(int argc, char* argv[], char* env[]) {
>   XMLPlatformUtils::Initialize();
> }
> Note that the crash doesn't occur on SUSE10 or any of the Redhat platforms.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-1877) Windows paths are not handled properly under cygwin

2018-01-30 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345893#comment-16345893
 ] 

Roger Leigh commented on XERCESC-1877:
--

>From the above cygwin documentation link: "Using native Win32 paths in Cygwin, 
>while often possible, is generally inadvisable. Those paths circumvent all 
>internal integrity checking and bypass the information given in the Cygwin 
>mount table."

 

I think the expectation is that you'll use POSIX paths like 
/cygdrive/c/tmp/personal.xml, since there are all sorts of subtle problems 
which can arise from using Win32 paths where POSIX paths are assumed.  In 
practice, the POSIX file manager works just fine.

 

I wonder if the behaviour can be simplified with C++17 std::filesystem::path 
when using a sufficiently modern system, since it would supersede both the 
POSIX and Win32 file managers.

> Windows paths are not handled properly under cygwin
> ---
>
> Key: XERCESC-1877
> URL: https://issues.apache.org/jira/browse/XERCESC-1877
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 3.0.1
> Environment: Cygwin with Xerces 3.0.1 built with ./configure and then 
> make
>Reporter: Mathieu Champlon
>Priority: Minor
>
> The Cygwin version of Xerces appears to be using the PosixFileMgr and 
> therefore isRelative returns false for a path starting with c: whereas it is 
> totally valid.
> To reproduce the issue copy samples/data/personal.xml (and personal.dtd) into 
> c:\tmp and run DOMCount as follows.
> $ pwd
> /cygdrive/c/Users/Mat/Desktop/dev/cpp/xerces-c-3.0.1/samples
> $ ls c:/tmp
> personal.dtd  personal.xml
> $ ./DOMCount.exe c:/tmp/personal.xml
> Fatal Error at file , line 0, char 0
>   Message: unable to open primary document entity 
> '/cygdrive/c/Users/Mat/Desktop
> /dev/cpp/xerces-c-3.0.1/samples/c:/tmp/personal.xml'
> Errors occurred, no output available
> ***
> Then I added the following lines taken from WindowsFileMgr to 
> PosixFileMgr::isRelative :
> #ifdef  __CYGWIN__
> if (toCheck[1] == chColon)
> {
> if (((toCheck[0] >= chLatin_A) && (toCheck[0] <= chLatin_Z))
> ||  ((toCheck[0] >= chLatin_a) && (toCheck[0] <= chLatin_z)))
> {
> return false;
> }
> }
> #endif
> With the following line at the top of PoxisFileMgr.cpp :
> #include 
> I recompiled the samples and ran DOMCount once again :
> $ ./DOMCount.exe c:/tmp/personal.xml
> c:/tmp/personal.xml: 67 ms (37 elems).
> The #ifdef __CYGWIN__ is probably not the way to go but it shows exactly 
> where the problem is.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (XERCESC-2134) Remove non-functional Win32MsgLoader code

2018-02-12 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2134.
--
   Resolution: Fixed
Fix Version/s: 3.2.1

Fixed in r1823971 which removes the unused code.

> Remove non-functional Win32MsgLoader code
> -
>
> Key: XERCESC-2134
> URL: https://issues.apache.org/jira/browse/XERCESC-2134
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
> Attachments: 0001-Remove-unused-and-broken-Win32MsgLoader.patch
>
>
> The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was 
> copied from, so all Windows builds are currently defaulting to the 
> InMemoryMsgLoader.  This is an unintentional omission which is simple to 
> correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-13 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2136:


 Summary: Add support for versioning sources and documentation 
automatically
 Key: XERCESC-2136
 URL: https://issues.apache.org/jira/browse/XERCESC-2136
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build, Utilities
Affects Versions: 3.2.0
Reporter: Roger Leigh
Assignee: Roger Leigh


Making a release requires a number of manual updates to various files including:
 * configure.ac
 * versions.incl
 * xerces-c.spec
 * src/xercesc/util/XercesVersion.hpp
 * doc/style/dtd/entities.ent
 * doc/source-repository.xml
 * doc/Doxyfile

It would be more efficient to make the majority of these updates automatic.

 

I've worked on some simple updates to the autoconf and cmake builds to do the 
following:
 * move library versioning into configure.ac (no separate updates to 
versions.incl)
 * generate a Xerces_version_config.hpp header like the 
Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
 * generating entities.ent to automate docs version updates
 * making source-repository.xml use version entities to eliminate manual updates
 * generating Doxyfile to avoid manual version updates

 

This narrows down updates to two files:
 * configure.ac
 * xerces-c.spec

 

I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363084#comment-16363084
 ] 

Roger Leigh commented on XERCESC-2136:
--

Are there any files requiring manual updates which I've missed?

 

Also, I've added targets to generate the docs and API docs, and tied them to 
dist-hook, so "make dist" and "make distcheck" automatically generate and 
bundle the versioned docs.  So a release is as simple as updates to 
configure.ac/xerces-c.spec and autoreconf, configure and "make distcheck".

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-13 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2136:
-
Attachment: 0001-Automatically-generate-versioned-documentation-and-h.patch

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Attachments: 
> 0001-Automatically-generate-versioned-documentation-and-h.patch
>
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-13 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363242#comment-16363242
 ] 

Roger Leigh commented on XERCESC-2136:
--

Patch attached.  There's some annoying permissions issue breaking "make 
distcheck" when it runs distclean, which I'll continue to look into.  But if 
you wanted to try it out and see if any version numbers are still hardcoded and 
need updating, "make dist" will work.

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Attachments: 
> 0001-Automatically-generate-versioned-documentation-and-h.patch
>
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-16 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366853#comment-16366853
 ] 

Roger Leigh commented on XERCESC-2136:
--

So long as we've automated away most of the manual updates, it's at least a 
partial gain!

 

Unless there's anything else, I think we are ready to roll out another release 
candidate for approval.  Do you want to do it or shall I?

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
> Attachments: 
> 0001-Automatically-generate-versioned-documentation-and-h.patch
>
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (XERCESC-2137) CMake Build Doesn't Activate XERCES_MFC_SUPPORT

2018-02-16 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2137.
--
   Resolution: Fixed
Fix Version/s: 3.2.1

Thanks for testing.  Fixed in SVN revision 1824447.

> CMake Build Doesn't Activate XERCES_MFC_SUPPORT
> ---
>
> Key: XERCESC-2137
> URL: https://issues.apache.org/jira/browse/XERCESC-2137
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
> Environment: MS Visual Studio
>Reporter: Scott Morgan
>Priority: Major
> Fix For: 3.2.1
>
> Attachments: 0001-cmake-Add-mfc-debug-option.patch, 
> mfc_debug_cmake.patch
>
>
> The XERCES_MFC_SUPPORT define is needed for Visual Studio debug builds, it 
> activates some code in XMemory.hpp/cpp
> Should just be a case of detecting MSVC in the main CMakeLists.txt and adding 
> a '#cmakedefine XERCES_MFC_SUPPORT' line in 
> Xerces_autoconf_config.hpp.cmake.in



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-15 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2136.
--
   Resolution: Fixed
Fix Version/s: 3.2.1

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
> Attachments: 
> 0001-Automatically-generate-versioned-documentation-and-h.patch
>
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2136) Add support for versioning sources and documentation automatically

2018-02-15 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365408#comment-16365408
 ] 

Roger Leigh commented on XERCESC-2136:
--

Added in r1824295.

 

> Add support for versioning sources and documentation automatically
> --
>
> Key: XERCESC-2136
> URL: https://issues.apache.org/jira/browse/XERCESC-2136
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build, Utilities
>Affects Versions: 3.2.0
>    Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
> Attachments: 
> 0001-Automatically-generate-versioned-documentation-and-h.patch
>
>
> Making a release requires a number of manual updates to various files 
> including:
>  * configure.ac
>  * versions.incl
>  * xerces-c.spec
>  * src/xercesc/util/XercesVersion.hpp
>  * doc/style/dtd/entities.ent
>  * doc/source-repository.xml
>  * doc/Doxyfile
> It would be more efficient to make the majority of these updates automatic.
>  
> I've worked on some simple updates to the autoconf and cmake builds to do the 
> following:
>  * move library versioning into configure.ac (no separate updates to 
> versions.incl)
>  * generate a Xerces_version_config.hpp header like the 
> Xerces_autoconf_config.hpp header, for inclusion by XercesVersion.hpp
>  * generating entities.ent to automate docs version updates
>  * making source-repository.xml use version entities to eliminate manual 
> updates
>  * generating Doxyfile to avoid manual version updates
>  
> This narrows down updates to two files:
>  * configure.ac
>  * xerces-c.spec
>  
> I'll attach a patch once I've done some more testing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2137) CMake Build Doesn't Activate XERCES_MFC_SUPPORT

2018-02-15 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365536#comment-16365536
 ] 

Roger Leigh commented on XERCESC-2137:
--

The code in XMemory appears to be just stubs that delegate to operator 
new(size), and there are no callers in the tree.  As far as I can tell, it's 
completely pointless and does nothing at all!  We could likely delete them with 
no functional impact.

 

Did you need them for any specific purpose?  I'm not an MFC expert; if there's 
a good reason to have this we can write the necessary CMake logic to detect MFC 
support is available and enable it.  But if it's non-functional, we might be 
better removing it entirely?

 

> CMake Build Doesn't Activate XERCES_MFC_SUPPORT
> ---
>
> Key: XERCESC-2137
> URL: https://issues.apache.org/jira/browse/XERCESC-2137
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
> Environment: MS Visual Studio
>Reporter: Scott Morgan
>Priority: Major
>
> The XERCES_MFC_SUPPORT define is needed for Visual Studio debug builds, it 
> activates some code in XMemory.hpp/cpp
> Should just be a case of detecting MSVC in the main CMakeLists.txt and adding 
> a '#cmakedefine XERCES_MFC_SUPPORT' line in 
> Xerces_autoconf_config.hpp.cmake.in



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (XERCESC-2137) CMake Build Doesn't Activate XERCES_MFC_SUPPORT

2018-02-15 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365656#comment-16365656
 ] 

Roger Leigh commented on XERCESC-2137:
--

The fix is pretty straightforward.  I can apply this with a bit of extra 
documentation.

 

What's actually breaking here?  I do daily debug builds and I've never had a 
problem.  Does you project need to be explicitly using MFC stuff for this to be 
an issue?

> CMake Build Doesn't Activate XERCES_MFC_SUPPORT
> ---
>
> Key: XERCESC-2137
> URL: https://issues.apache.org/jira/browse/XERCESC-2137
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
> Environment: MS Visual Studio
>Reporter: Scott Morgan
>Priority: Major
> Attachments: mfc_debug_cmake.patch
>
>
> The XERCES_MFC_SUPPORT define is needed for Visual Studio debug builds, it 
> activates some code in XMemory.hpp/cpp
> Should just be a case of detecting MSVC in the main CMakeLists.txt and adding 
> a '#cmakedefine XERCES_MFC_SUPPORT' line in 
> Xerces_autoconf_config.hpp.cmake.in



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Reopened] (XERCESC-2114) Link failure with Xalan-C

2018-02-20 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh reopened XERCESC-2114:
--

This is still reproducible with 3.2.1rc3

 

Creating library 
D:\FILES-merge\af9fc46c\build\xalan-source\c\Build\Win64\VC14\Release\\Xalan-C_1.lib
 and object 
D:\FILES-merge\af9fc46c\build\xalan-source\c\Build\Win64\VC14\Release\\Xalan-C_1.exp
 2>XalanDiagnosticMemoryManager.obj : error LNK2001: unresolved external symbol 
"__declspec(dllimport) unsigned __int64 const `public: static unsigned __int64 
__cdecl 
xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
__int64)'::`2'::alignment" 
(__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]
 2>..\..\..\..\Build\Win64\VC14\Release\Xalan-C_1_11.dll : fatal error LNK1120: 
1 unresolved externals 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]

 

"D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\Xalan.sln" 
(AllInOne target) (1) -> 
"D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj"
 (default target) (2) -> (DoLinkOutputFilesMatch target) -> C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1189,5): 
warning MSB8012: 
TargetPath(D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\..\..\..\..\Build\Win64\VC14\Release\AllInOne.dll)
 does not match the Linker's OutputFile property value 
(D:\FILES-merge\af9fc46c\build\xalan-source\c\Build\Win64\VC14\Release\Xalan-C_1_11.dll).
 This may cause your project to build incorrectly. To correct this, please make 
sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the 
value specified in %(Link.OutputFile). 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]
 C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1191,5): 
warning MSB8012: TargetName(AllInOne) does not match the Linker's OutputFile 
property value (Xalan-C_1_11). This may cause your project to build 
incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) 
and $(TargetExt) property values match the value specified in 
%(Link.OutputFile). 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]
 "D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\Xalan.sln" 
(AllInOne target) (1) -> 
"D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj"
 (default target) (2) -> (Link target) -> XalanDiagnosticMemoryManager.obj : 
error LNK2001: unresolved external symbol "__declspec(dllimport) unsigned 
__int64 const `public: static unsigned __int64 __cdecl 
xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
__int64)'::`2'::alignment" 
(__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]
 ..\..\..\..\Build\Win64\VC14\Release\Xalan-C_1_11.dll : fatal error LNK1120: 1 
unresolved externals 
[D:\FILES-merge\af9fc46c\build\xalan-source\c\Projects\Win32\VC14\AllInOne\AllInOne.vcxproj]

 

I would be interested to know if anyone else can reproduce the failure with 
3.2.1rc3 on Windows with current Xalan-C.  It's not unlikely that the fault is 
with the Xalan build with VS2015, but it's potentially the case that there's 
something up with the Xerces-C symbol exports?

> Link failure with Xalan-C
> -
>
> Key: XERCESC-2114
> URL: https://issues.apache.org/jira/browse/XERCESC-2114
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>    Affects Versions: 3.2.0
>     Environment: VS2013 on Windows Server 2012R2
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>
> Testing latest rc1 with xalan and VS2013:
> [Build 
> log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]
> Using [this 
> patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
>  to build Xalan with VS2013 (it's just the upgraded project files).
> {noformat}
> 12:29:32(Link target) -> 
> 12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: 
> unresolved external symbol "__declspec(dllimport) unsigned __int64 const 
> `pub

[jira] [Updated] (XERCESC-2138) class xercesc_3_2::XSConstants only defines private constructors and has no friends

2018-02-21 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2138:
-
Attachment: 0002-Drop-XERCES_HAS_CPP_NAMESPACE-check.patch
0001-Make-XSConstants-a-namespace.patch

> class xercesc_3_2::XSConstants only defines private constructors and has no 
> friends
> ---
>
> Key: XERCESC-2138
> URL: https://issues.apache.org/jira/browse/XERCESC-2138
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
>Reporter: Johnny Willemsen
>Priority: Trivial
> Attachments: 0001-Make-XSConstants-a-namespace.patch, 
> 0002-Drop-XERCES_HAS_CPP_NAMESPACE-check.patch
>
>
> When compiling xercesc-3.2.0 with mingw-64 gcc 4.9.3 on Windows we get a lot 
> of warnings, for example:
> class xercesc_3_2::XSConstants' only defines private constructors and has no 
> friends
>  In file included from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSObject.hpp:26:0,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSTypeDefinition.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSSimpleTypeDefinition.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/validators/datatype/DatatypeValidator.hpp:32,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLAttr.hpp:28,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLValidator.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/sax2/SAX2XMLReader.hpp:27,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/samples/src/SAX2Print/SAX2Print.cpp:28:
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc] 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSConstants.hpp:56:24:
>  warning: 'class xercesc_3_2::XSConstants' only defines private constructors 
> and has no friends [-Wctor-dtor-privacy]
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  class XMLPARSER_EXPORT XSConstants 
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc] ^



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (XERCESC-2138) Xerces-C++ should use C++98 features and remove pre-Standard workarounds

2018-02-21 Thread Roger Leigh (JIRA)

[ 
https://issues.apache.org/jira/browse/XERCESC-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372208#comment-16372208
 ] 

Roger Leigh edited comment on XERCESC-2138 at 2/21/18 11:27 PM:


I've attached a few patches which clean up some particular old features, 
enabling namespaces and standard header usage by default.  There's much more 
which could be cleaned up; this is just a demonstration.

 

Interestingly, with the above patches, it uncovers a *lot* of extra warnings.  
Many would be resolved with the appropriate C++ casts, but there could be a 
number of bugs lurking in there which were previously hidden from sight.  
Fixing all this stuff up could potentially improve the quality of the 
implementation, so might be worth considering for a point release.  While the 
above diffs might look scary, there are no API changes and it's primarily 
removal of autoconf/cmake checks which are pointless with a standard C++ 
implementation.

 

Edit: the extra warnings might actually be from upgrading to GCC 7.3 and 
unrelated to the patches.


was (Author: rleigh):
I've attached a few patches which clean up some particular old features, 
enabling namespaces and standard header usage by default.  There's much more 
which could be cleaned up; this is just a demonstration.

 

Interestingly, with the above patches, it uncovers a *lot* of extra warnings.  
Many would be resolved with the appropriate C++ casts, but there could be a 
number of bugs lurking in there which were previously hidden from sight.  
Fixing all this stuff up could potentially improve the quality of the 
implementation, so might be worth considering for a point release.  While the 
above diffs might look scary, there are no API changes and it's primarily 
removal of autoconf/cmake checks which are pointless with a standard C++ 
implementation.

> Xerces-C++ should use C++98 features and remove pre-Standard workarounds
> 
>
> Key: XERCESC-2138
> URL: https://issues.apache.org/jira/browse/XERCESC-2138
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
>Reporter: Johnny Willemsen
>Priority: Trivial
> Attachments: 0001-Make-XSConstants-a-namespace.patch, 
> 0002-Drop-XERCES_HAS_CPP_NAMESPACE-check.patch, 
> 0003-Drop-XERCES_STD_NAMESPACE-check.patch, 
> 0004-Drop-XERCES_NO_NATIVE_BOOL-check.patch, 
> 0005-Drop-XERCES_NEW_IOSTREAMS-check.patch, 
> 0006-Use-cstdlib-in-place-of-stdlib.h.patch, 
> 0007-Use-cstdio-in-place-of-stdio.h.patch, 
> 0008-Use-cstring-in-place-of-string.h.patch, 
> 0009-Remove-use-of-strings.h.patch
>
>
> When compiling xercesc-3.2.0 with mingw-64 gcc 4.9.3 on Windows we get a lot 
> of warnings, for example:
> class xercesc_3_2::XSConstants' only defines private constructors and has no 
> friends
>  In file included from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSObject.hpp:26:0,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSTypeDefinition.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSSimpleTypeDefinition.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/validators/datatype/DatatypeValidator.hpp:32,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLAttr.hpp:28,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLValidator.hpp:25,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc]  from 
> C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/sax2/SAX2XMLReader.hpp:27,
> Gandalf_win10_x86_64_01(administrator@172.16.2.213) 
> [pkg_xercesc:windows-pkg-xercesc] 

[jira] [Resolved] (XERCESC-2114) Link failure with Xalan-C

2018-02-21 Thread Roger Leigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh resolved XERCESC-2114.
--
   Resolution: Fixed
Fix Version/s: 3.2.1

Fixed in 1825016.

None of the extra compiler flags were necessary (and were, in fact, responsible 
for the later failure I saw).  This minimal change makes everything work in all 
downstream projects for me.  [~mat] suggested moving it out of the header, but 
this simple change allows it to remain directly inline, and there should be no 
performance impact since everything is a compile-time constant that should 
allow the compiler to trivially eliminate all the code.

[~canto...@osu.edu] Would it be possible to make an rc4 with this final change 
included.  That's the last problem I was aware of, so hopefully that will be 
the last rc!

> Link failure with Xalan-C
> -
>
> Key: XERCESC-2114
> URL: https://issues.apache.org/jira/browse/XERCESC-2114
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.0
> Environment: VS2013 on Windows Server 2012R2
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.1
>
>
> Testing latest rc1 with xalan and VS2013:
> [Build 
> log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console]
> Using [this 
> patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff]
>  to build Xalan with VS2013 (it's just the upgraded project files).
> {noformat}
> 12:29:32(Link target) -> 
> 12:29:32  XalanDiagnosticMemoryManager.obj : error LNK2001: 
> unresolved external symbol "__declspec(dllimport) unsigned __int64 const 
> `public: static unsigned __int64 __cdecl 
> xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned 
> __int64)'::`2'::alignment" 
> (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB)
>  
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> 12:29:32  ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : 
> fatal error LNK1120: 1 unresolved externals 
> [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj]
> {noformat}
> Is there any incompatible change expected here?  Could potentially be missing 
> symbol exports or anything of that nature?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



<    1   2   3   >