[GitHub] [xerces-c] rleigh-codelibre opened a new pull request #13: XERCESC-2202: Update version to 3.3.0
rleigh-codelibre opened a new pull request #13: URL: https://github.com/apache/xerces-c/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124275#comment-17124275 ] Roger Leigh commented on XERCESC-2141: -- In the interim, contemporary compilers are going to be enabling C++17 by default, so I've added this in addition to C++11 and C++14 for both Autoconf and CMake. > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Labels: autoconf build c++11 c++14 c++17 (was: autoconf build c++11 c++14) > Enable C++11/14/17 with autoconf build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Summary: Enable C++11/14/17 with autoconf build and CMake build (was: Enable C++11/14/17 with autoconf build) > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Summary: Enable C++11/14/17 with autoconf build (was: Enable C++11/14 with autoconf build) > Enable C++11/14/17 with autoconf build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2141) Enable C++11/14 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2141: Assignee: Roger Leigh > Enable C++11/14 with autoconf build > --- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2202) Update version of master branch to 3.3.0
Roger Leigh created XERCESC-2202: Summary: Update version of master branch to 3.3.0 Key: XERCESC-2202 URL: https://issues.apache.org/jira/browse/XERCESC-2202 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre opened a new pull request #12: Use C++98 features and remove pre-Standard workarounds
rleigh-codelibre opened a new pull request #12: URL: https://github.com/apache/xerces-c/pull/12 See [XERCESC-2138](https://issues.apache.org/jira/browse/XERCESC-2138). This is the first of several changes on the master branch for 3.3.0 (or maybe 4.0.0 if considered too divergent from 3.2.x). This one is large but fairly conservative. It brings the codebase up to a minimum of C++98, removing a number of workarounds for obsolete systems and compilers. This should have zero consequence for any system supporting basic C++98 features. * namespaces are required and used * `bool` is assumed to be present as a native type * C++ standard library is assumed to be present and using the `std::` namespace * `` is assumed to be standard * ``, `` and `` are assumed to be present * `const`, `inline` and `volatile` are assumed to be present This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2201) Update Travis-CI image in use
Roger Leigh created XERCESC-2201: Summary: Update Travis-CI image in use Key: XERCESC-2201 URL: https://issues.apache.org/jira/browse/XERCESC-2201 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Update image to use current image e.g. Ubuntu 20.04 LTS, which should see us supported for some time into the future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2200) Update AppVeyor image in use
Roger Leigh created XERCESC-2200: Summary: Update AppVeyor image in use Key: XERCESC-2200 URL: https://issues.apache.org/jira/browse/XERCESC-2200 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 AppVeyor images haven't been upgraded for some time. Update to newer image with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
