[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069093#comment-16069093
]
Roger Leigh commented on XERCESC-2077:
--
Hi Franz,
You're most welcome, and I'm glad that the work is useful and appreciated! If
you have any suggestions on improving it, or run into any problems, don't
hesitate to get in touch.
Kind regards,
Roger
> 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,
> cmake_bcb5_err.zip, 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 regener
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068815#comment-16068815
]
Franz Beaune commented on XERCESC-2077:
---
Hey Roger,
I just created an account here to say a massive "thank you" for your truly
amazing work! It is a huge relief to move to a more modern build system like
CMake, even if it has its own quirks.
Your CMake setup worked wonderfully on the first try (on Windows with VS 2015).
>From an open source maintainer [1] to another: Thanks again!!
Franz
[1] http://appleseedhq.net/
> 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,
> cmake_bcb5_err.zip, 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
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 Vis
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002699#comment-16002699
]
Scott Cantor commented on XERCESC-2077:
---
That's good. If it's not too onerous, can you give me maybe a week to review
some of that, and if I haven't had a chance by then, I'd say go ahead and check
it into trunk. I've finished my compare so any changes on trunk won't impact my
work much.
> 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 edited
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983444#comment-15983444
]
Scott Cantor commented on XERCESC-2077:
---
I doubt anything you did would be a risk, but any testing of trunk for any
reason is incredibly welcome because that's the main sticking point to getting
it released.
> 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
>
>
> 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 par
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983441#comment-15983441
]
Roger Leigh commented on XERCESC-2077:
--
Now rebased onto trunk. I'm looking at re-running our test CI jobs on the new
branch to verify it's working the same as the older patch for 3.1, but given
that there are zero changes I don't expect any problems--it passed all the
tests on the platform I tested it on by hand.
> 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
>
>
> 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 fr
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978774#comment-15978774
]
Scott Cantor commented on XERCESC-2077:
---
(Though I suppose the least risky way forward would be to branch either trunk
or 3.1 maint and do the initial work and testing there.)
> 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
>
>
> 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
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978767#comment-15978767
]
Scott Cantor commented on XERCESC-2077:
---
This project is, to put it mildly, languishing. I'm willing to review to a
point, but my main point of focus is "not breaking the existing build process"
right now.
There's no CI, though there are tests I'm totally unfamiliar with but that seem
to run to some degree.
I'm not aware of any development material, all I've done is patching.
The real question, I think, is which branch. I am leaning towards spending some
time this summer to get a 3.2 out for personal reasons. Simply from a risk
reduction standpoint, it would make more sense to look at putting these changes
on that branch anyway (which is to say trunk, that's where 3.2 dev is).
I would encourage you to post a general outline of what you'll do to trunk to
c-dev and give it a couple of days, and then I say go.
> 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
>
>
> 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 wi
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978377#comment-15978377
]
Roger Leigh commented on XERCESC-2077:
--
Looks like I now have an Apache account. What's the next step here? Is there
a formal review process for this? Is there any Apache-internal continuous
integration stuff to set up? Or any documentation regarding development
workflows I should read up?
Thanks,
Roger
> 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
>
>
> 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
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722373#comment-15722373
]
Scott Cantor commented on XERCESC-2077:
---
I'll follow up off-Jira and see where we are on commit acccess and such.
> 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
>
>
> 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
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721891#comment-15721891
]
Roger Leigh commented on XERCESC-2077:
--
The CLA was finally submitted, so this should be good to merge now from that
point of view. I'll be happy to make any further revisions to the code, should
any be required.
> 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
>
>
> 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 o
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466705#comment-15466705
]
Roger Leigh commented on XERCESC-2077:
--
[~snikulov] It's waiting on my employer to get all the CLA paperwork sorted
out. Still haven't got a concrete date for a meeting with the copyright
people; they are all unavailable over the summer... but hopefully should be
sometime in the next month or so (according to my boss, who is equally helpless
here). Sorry about that; university bureaucracy is incredibly annoying to deal
with. Feel free to use the patch in the meantime though!
> 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
>
>
> 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
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466694#comment-15466694
]
Sergei Nikulov commented on XERCESC-2077:
-
[~rleigh] Whan it will be released?
> 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
>
>
> 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 categor
[jira] [Commented] (XERCESC-2077) Add CMake build system
[
https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378624#comment-15378624
]
Roger Leigh commented on XERCESC-2077:
--
Unrelated to the patch, but the extensive CI testing showed a few problems
which may have been missed. Some of the compiler warnings may warrant further
investigation such as macosxunicodeconverter calling sizeof on an array
function argument, and there may also be an issue with the thread tests on
FreeBSD. I'll files separate tickets, with patches where possible, as I
investigate them in more detail.
> 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
>
>
> 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 d
