On 16/05/2017 16:37, Cantor, Scott wrote:
Additionally, if anyone wanted to review and test the patch, it's
attached to the above ticket and also available here:
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
Playing with this now, I had two issues I wanted to ask about. One is that it
looks like there definitely is a lot of overlap with the material we have to
maintain for autoconf, and I'm just concerned about the dual maintenance of it
or the possibility of it falling out of sync since nobody else really knows
cmake.
There's certainly a good amount of duplication, most of it intentionally
so that the CMake logic mirrors the existing Autoconf feature tests
exactly. This is so it can be a drop-in replacement in every respect;
we could have gone with a more CMake-native approach in some cases, or
dropped some historical parts entirely. Most if it is needed to support
all the configurable options so that we're exactly reproducing the same
#defines in the configuration header, and doing exactly the same
conditional compilation.
It would have been great if there was some way to share the logic
between the two. The snippets of program code used for feature tests
might be shared, but they are so small and trivial that it's likely not
worth it.
One place we can definitely share code is the unit test output. Here,
we add test output files, one per unit test, for validating the tests.
This permits individual tests to be run, run in parallel (and it also
fixes the tests on FreeBSD where there are issues with newlines at the
end of file for some reason). We could make automake "make check" use
these as well, replacing the perl script currently in use, which will
make the autotools testing a bit more accessible and transparent, as
well as a bit more portable. I can certainly look at this as a followup
task.
Leaving aside whether it's a good or bad idea, if we wanted to standardize on
this, does the cmake system generate actual autoconf-compatible build files
(i.e. you run configure?) or does it take over that role. I think the latter is
a non-starter given the prevalence of autoconf assumptions across the
landscape. And if so, that does raise maintenance concerns.
I'm not entirely sure about the question you're asking here. By
autoconf-compatible build files, you're talking about the end result of
configure--the generated Makefiles and headers, or the intermediate
autoconf/make scripts like configure/Makefile.in?
CMake and its CMakeLists.txt file are equivalent to
autoconf/automake/autoheader/libtoolize and configure.ac, Makefile.am,
config.h.in etc. along with the generated Makefile.in/configure etc.
CMake is a single tool which generates build files for any supported
build system by evaluating the CMakeLists.txt script. In the case of
its "Unix Makefiles" generator, this generates Makefiles and headers
just like configure, but without any intermediate scripts being needed.
The Makefiles are broadly equivalent in terms of supported targets like
"make install"; and when running cmake, you can configure all the
options and path prefixes almost the same as configure (the names are
slightly different but the intent is the same).
While on Unix this is certainly duplicating much of the autotools logic,
and could potentially replace autotools entirely, the real gain (and the
intention for doing this) is the vastly improved support for Windows.
I'd suggest that the cost of the duplication is outweighed by the
existing maintenance burden of the Visual Studio solutions, which was
often externalised since people like myself had to hand-patch every
release to make them work with ICU, newer Visual Studio versions etc.
With CMake, we just run cmake with the desired options, and we're done,
and we can directly integrate this with other projects.
Secondly, I'm mainly playing with the Windows side of this, and I was unclear
if it's possible to generate solution files for both 32- and 64-bit at once? It
looks like it picks one to do at a time so that if you had to build both you'd
have to generate the whole set of files twice in between or use separate
unpacked trees, etc. Is that correct?
Yes, as you mentioned in your other reply, you need to use separate
build directories for each compiler/platform combination; you can use a
common source tree. On Windows, you can
- Choose the developer command prompt of your choice, and then use the
"-G" option to select the "NMake, "Ninja" or any other generator of your
choice.
- Use the "Visual Studio nn yyyy [Win64]" generator from a regular
command prompt, and it will set up the compiler environment for you;
build with "msbuild" or open up the solution in Visual Studio.
- Use Cygwin or MinGW with the "Unix Makefiles" or any other generator
of choice
So CMake does make building
> One issue I did notice on the Windows side is that the DLL names are
> different from the existing convention. I would have to personally
> adjust them back and I don't think we'd have any reason to want them
> changed, so I assume that could be adjusted back?
I think it's fairly simple to change; I'll have to check. The same also
applies to the full .so version on Unix, which isn't identical to
libtool in its pattern. Same name to link with, and same SOVERSION
symlink, but the library itself has a slightly different pattern.
The question I have here is this: why is the link name different on
Windows? With CMake being cross-platform, it would allow the naming and
versioning conventions to be the same on both Unix and Windows. This is
a usability gain when a cross-platform downstream project wants to link
with xerces: right now they have to hardcode the discrepancy. I'm sure
we can tweak it to retain the existing platform-specific conventions
with a few additional bits of configuration, however.
Kind regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
