On 16/05/2017 19:02, Cantor, Scott wrote:
There's certainly a good amount of duplication, most of it intentionally
so that the CMake logic mirrors the existing Autoconf feature tests
exactly.
Right, I understand the motivation. And Xerces has one of the more horrendous
config.h messes I've dealt with, it wouldn't necessarily be so much work in
every project.
Definitely not; this is the most complex conversion I've done to date.
The previous most complex one was libtiff, which also had a fair amount
of historical stuff. Most are trivial in comparison.
I'm not entirely sure about the question you're asking here. By
autoconf-compatible build files, you're talking about the end result of
configure--the generated Makefiles and headers, or the intermediate
autoconf/make scripts like configure/Makefile.in?
No, the intermediates. People *want*, virtually *demand* the ability to do source builds
with configure/make/make install and any violation of the norm is just painful for
anybody using Xerces in their projects together with dozens of other libraries all
expecting to be built that way. "Different" is bad in this context.
Ah, OK. In the case where we wanted to drop the Autotools and maintain
just one system, it would be absolutely possible to create a wrapper
"configure" script which forwards all the expected arguments to cmake.
Certainly for all prefixes, flags, --with/--enable options etc.
Likewise with any target name differences--we can create proxy targets
to forward to the real target. The only problem might be more esoteric
cases, like cross-compilation, where it wouldn't be trivial to wrap. We
could certainly cater for the common case scenarios though.
Hopefully I got the question you were asking. I didn't do this in the
patch because the intention was not to replace the Autotools. But I can
look into this if desired.
I think it's fairly simple to change; I'll have to check. The same also
applies to the full .so version on Unix, which isn't identical to
libtool in its pattern. Same name to link with, and same SOVERSION
symlink, but the library itself has a slightly different pattern.
I'm not a fan of the non-soname versioning used, but there's backstory there
and I don't think we want to re-litigate it, so the convention there has been
to embed the ABI version in the name (libxerces-c-3.1.so, new one will be
libxerces-c-3.2.so)
OK
The question I have here is this: why is the link name different on
Windows? With CMake being cross-platform, it would allow the naming and
versioning conventions to be the same on both Unix and Windows. This is
a usability gain when a cross-platform downstream project wants to link
with xerces: right now they have to hardcode the discrepancy. I'm sure
we can tweak it to retain the existing platform-specific conventions
with a few additional bits of configuration, however.
Most projects don't have any cross platform build tooling for Linux and
Windows, so the name difference doesn't really come up much. On the Windows
side, it's critical for the ABI version tag and a D (for debug) be present, but
I'm not personally wedded to anything in particular other than, again, not
wanting to engage in a bikeshedding discussion about it, so leaving it
consistent with 3.1 seemed the simplest choice.
If there's value in aligning with the Linux names, though, I'm not really
opposed personally, but Linux doesn't have the debug/non-debug distinction
either, so I don't think they could really be identical anyway...
OK. I'll look into copying the existing Windows and Libtool semantics
exactly. If there's a possibility for aligning them with the next major
release, we could revisit it then, but I'll revert to the status quo for
now.
I've successfully built various combinations of the Windows build and I get the
gist of it.
I guess for myself, my comfort level would go up a bit if there was just a
brief sort of outline of how a given AC_DEFINE or Windows #define would be
added to the cmake build if it became needed. If I had some comfort level with
how it works, the duplication wouldn't bother me too much.
This is pretty straightforward:
src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in is the template.
It's the same as src/xercesc/util/Xerces_autoconf_config.hpp.in with
these exceptions:
- "#cmakedefine var 1" is used in place of "#undef var" for Boolean macros
- "#define var @var@" is used for substitutions of types and values with
direct replacement of the @var@, just like in configure .in files.
- It also includes the missing Windows logic which wasn't needed for the
Unix-only autoconf template
The header is generated from the template by the configure_file in the
root CMakeLists.txt:
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/src/xercesc/util/Xerces_autoconf_config.hpp
@ONLY)
The @ONLY means only @var@ substitions are allowed (no ${var}).
There is no AC_DEFINE equivalent; there is no autoheader, and the
substitutions are regular variables, so
set(var ON|OFF|TRUE|FALSE|1|0) -- Boolean
set(var some-value) -- string
will work for both types of substitution in the template.
All of the feature tests set a variable for propagation into the
template. Example: each header test in cmake/XercesIncludes.cmake sets
the a specified result variable which we then use directly. They are
named exactly the same as the autoconf variables to make the direct
equivalence clear. Or in the case of cmake/XercesDLL.cmake we set
XERCES_PLATFORM_EXPORT and XERCES_PLATFORM_IMPORT which are then
substituted into the header.
I hope that explains things, but I'm happy to go into more detail for
any aspects which are unclear.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
