You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Cantor, Scott" <ca...@osu.edu> on 2017/05/16 16:37:25 UTC
RE: Integrating CMake support for xerces
> 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.
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.
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?
-- Scott
Re: Integrating CMake support for xerces
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Roger Leigh <rl...@codelibre.net> writes:
> If we every wanted to drop the Autotools to only have one system to
> maintain, this would provide compatibility with a traditional
> configure/make/make install workflow. I'm not suggesting doing this at this
> point in time, just wanted to mention the existence of this solution as a
> possibility for the future.
It would still require CMake to be installed, right? One of the main
advantages of autotools is all you need is a compiler (and make),
everything else is included.
I think if we drop autotools, then we drop them good, without hitching
ourselves to some half-solutions with questionable long-term prospects.
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 16/05/17 20:02, Cantor, Scott wrote:
>> 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.
I came across this today, so thought I'd mention it:
https://github.com/nemequ/configure-cmake
This is a "configure" shell script you drop into a CMake-using project
to wrap the invocation of cmake with an Autoconf-like shell script,
which maps all the standard configure options to the cmake equivalents.
If we every wanted to drop the Autotools to only have one system to
maintain, this would provide compatibility with a traditional
configure/make/make install workflow. I'm not suggesting doing this at
this point in time, just wanted to mention the existence of this
solution as a possibility for the future.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by rl...@codelibre.net.
On 2017-05-17 17:30, Cantor, Scott wrote:
> On 5/17/17, 12:21 PM, "rleigh@codelibre.net" <rl...@codelibre.net>
> wrote:
>
>> I spoke too soon; it's not working for the VS generators on Windows
>> when
>> using multiple configurations. I'll fix this up tomorrow.
>
> FWIW, the names currently are the same for 32 and 64 builds. That
> probably is as much because of the timing of them being added, but it
> does also relate to the cross-platform point you had, people on
> Windows doing dual arch builds don't tend to use different names for
> the files (at least not that I've seen) since they tend to just copy
> their old makefiles and projects to 64-bit.
The issue was more related to the debug/release DLL names in the .rc
file than 32/64-bit names. I've fixed this detail up, and updated the
patch is in JIRA. It should now work across to board.
https://issues.apache.org/jira/secure/attachment/12868727/0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 5/17/17, 12:21 PM, "rleigh@codelibre.net" <rl...@codelibre.net> wrote:
> I spoke too soon; it's not working for the VS generators on Windows when
> using multiple configurations. I'll fix this up tomorrow.
FWIW, the names currently are the same for 32 and 64 builds. That probably is as much because of the timing of them being added, but it does also relate to the cross-platform point you had, people on Windows doing dual arch builds don't tend to use different names for the files (at least not that I've seen) since they tend to just copy their old makefiles and projects to 64-bit.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by rl...@codelibre.net.
On 2017-05-17 16:35, rleigh@codelibre.net wrote:
> On 2017-05-17 16:26, Cantor, Scott wrote:
>> On 5/17/17, 11:11 AM, "rleigh@codelibre.net" <rl...@codelibre.net>
>> wrote:
>>
>>> I've attached a followup patch, also on my cmake-trunk github branch,
>>> which does this. With this patch applied, you should get identical
>>> versioning to Autoconf and Visual Studio.
>>
>> Great, I'm WfH today but I'll see what it does on OS X today and
>> re-test Windows tomorrow at the office.
>>
>> Maybe we could look at doing the svn merge next week?
>
> That sounds great. I'm in the process of re-running all the 256 CI
> builds again; no failures so far.
I spoke too soon; it's not working for the VS generators on Windows when
using multiple configurations. I'll fix this up tomorrow.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by rl...@codelibre.net.
On 2017-05-17 16:26, Cantor, Scott wrote:
> On 5/17/17, 11:11 AM, "rleigh@codelibre.net" <rl...@codelibre.net>
> wrote:
>
>> I've attached a followup patch, also on my cmake-trunk github branch,
>> which does this. With this patch applied, you should get identical
>> versioning to Autoconf and Visual Studio.
>
> Great, I'm WfH today but I'll see what it does on OS X today and
> re-test Windows tomorrow at the office.
>
> Maybe we could look at doing the svn merge next week?
That sounds great. I'm in the process of re-running all the 256 CI
builds again; no failures so far.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 5/17/17, 11:11 AM, "rleigh@codelibre.net" <rl...@codelibre.net> wrote:
> I've attached a followup patch, also on my cmake-trunk github branch,
> which does this. With this patch applied, you should get identical
> versioning to Autoconf and Visual Studio.
Great, I'm WfH today but I'll see what it does on OS X today and re-test Windows tomorrow at the office.
Maybe we could look at doing the svn merge next week?
-- Scott
RE: Integrating CMake support for xerces
Posted by rl...@codelibre.net.
On 2017-05-16 21:47, Cantor, Scott wrote:
>> 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.
>
> Thx.
>
>> I hope that explains things, but I'm happy to go into more detail for
>> any aspects which are unclear.
>
> Thanks, I'll review further while you make the filename adjustments
> but I think if others don't have concerns we can plan for merging it
> back to trunk.
I've attached a followup patch, also on my cmake-trunk github branch,
which does this. With this patch applied, you should get identical
versioning to Autoconf and Visual Studio.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
> 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.
Good to know.
> 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.
Not at the moment, I was just trying to understand the relationship between the tools and the implications of having both on the maintenance.
> 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.
Thx.
> I hope that explains things, but I'm happy to go into more detail for
> any aspects which are unclear.
Thanks, I'll review further while you make the filename adjustments but I think if others don't have concerns we can plan for merging it back to trunk.
-- Scott
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Vitaly Prapirny wrote on 22/06/2017 10:53:
> Roger Leigh wrote on 21/06/2017 17:40:
>> That line (PlatformUtils.cpp:27) is
>>
>> #if HAVE_CONFIG_H
>> # include <config.h>
>> #endif
>>
>> so it either can't cope with "#if xxx" (which is used in many
>> places), or the error is in the generated "config.h". I'm afraid
>> you'll need to identify the cause of the error here. Can you include
>> config.h in a single test file like this:
>>
>> #if HAVE_CONFIG_H
>> # include <config.h>
>> #endif
>>
>> int main()
>> {}
>>
>> with or without the #if/endif? If you can pinpoint where the problem
>> is, we can look at further fixes.
> Compilation of that single test file failed with just the same error
> "Expression syntax" when HAVE_CONFIG_H defined without value
> (-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or
> defined with value (-DHAVE_CONFIG_H=1)
Roger,
After you fix that, I've got another error:
[ 80%] Linking CXX shared library xerces-c.dll
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Error E2194: Could not find file '@CMakeFiles\xerces-c.dir\objects1.rsp'
Good luck!
Vitaly
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Roger Leigh wrote on 21/06/2017 17:40:
> That line (PlatformUtils.cpp:27) is
>
> #if HAVE_CONFIG_H
> # include <config.h>
> #endif
>
> so it either can't cope with "#if xxx" (which is used in many places),
> or the error is in the generated "config.h". I'm afraid you'll need
> to identify the cause of the error here. Can you include config.h in
> a single test file like this:
>
> #if HAVE_CONFIG_H
> # include <config.h>
> #endif
>
> int main()
> {}
>
> with or without the #if/endif? If you can pinpoint where the problem
> is, we can look at further fixes.
Compilation of that single test file failed with just the same error
"Expression syntax" when HAVE_CONFIG_H defined without value
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or defined
with value (-DHAVE_CONFIG_H=1)
Good luck!
Vitaly
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/06/17 14:53, Vitaly Prapirny wrote:
> Roger Leigh wrote on 21/06/2017 13:58:
>> Sorry, too hasty. Please try this revised patch which actually works.
>
> CMake worked without error, but compilation failed just the same way as
> in my previous message.
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
# include <config.h>
#endif
so it either can't cope with "#if xxx" (which is used in many places),
or the error is in the generated "config.h". I'm afraid you'll need to
identify the cause of the error here. Can you include config.h in a
single test file like this:
#if HAVE_CONFIG_H
# include <config.h>
#endif
int main()
{}
with or without the #if/endif? If you can pinpoint where the problem
is, we can look at further fixes.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Roger Leigh wrote on 21/06/2017 13:58:
> Sorry, too hasty. Please try this revised patch which actually works.
CMake worked without error, but compilation failed just the same way as
in my previous message.
Good luck!
Vitaly
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/06/17 11:17, Roger Leigh wrote:
>
>
> On 21/06/17 10:46, Vitaly Prapirny wrote:
>> Roger Leigh wrote on 21/06/2017 12:20:
>>> On 21/06/17 08:48, Vitaly Prapirny wrote:
>>>> I've got an error while running cmake with "Borland Makefiles"
>>>> generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?
>>>
>>> It's not a combination I've personally tested, but I can't see any
>>> evidence that it shouldn't work.
>>>
>>> What are the errors you are seeing? Maybe it just needs a few minor
>>> tweaks to our cmake logic.
>> I've attached log files to the
>> https://issues.apache.org/jira/browse/XERCESC-2077
>
> Thanks. This was a problem with the int type check fallbacks. Please
> see the attached patch or this github branch:
> https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback
Sorry, too hasty. Please try this revised patch which actually works.
Roger
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Roger Leigh wrote on 21/06/2017 13:17:
> Thanks. This was a problem with the int type check fallbacks. Please
> see the attached patch or this github branch:
> https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback
>
> This was a search-replace error when porting m4/xerces_int_types, and
> all the systems I've tested on all had stdint.h or cstdint, so I
> didn't notice this wasn't working. I've switched all the types to be
> unambiguously signed, and added SIGNED_ to all the variable names
> where missing.
>
> If you could give that a go, I'd be very interested if this works for
> you, or if you hit any other problems after this point.
CMake worked without error in that branch, but compilation failed (make
log attached).
Good luck!
Vitaly
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/06/17 10:46, Vitaly Prapirny wrote:
> Roger Leigh wrote on 21/06/2017 12:20:
>> On 21/06/17 08:48, Vitaly Prapirny wrote:
>>> I've got an error while running cmake with "Borland Makefiles"
>>> generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?
>>
>> It's not a combination I've personally tested, but I can't see any
>> evidence that it shouldn't work.
>>
>> What are the errors you are seeing? Maybe it just needs a few minor
>> tweaks to our cmake logic.
> I've attached log files to the
> https://issues.apache.org/jira/browse/XERCESC-2077
Thanks. This was a problem with the int type check fallbacks. Please
see the attached patch or this github branch:
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback
This was a search-replace error when porting m4/xerces_int_types, and
all the systems I've tested on all had stdint.h or cstdint, so I didn't
notice this wasn't working. I've switched all the types to be
unambiguously signed, and added SIGNED_ to all the variable names where
missing.
If you could give that a go, I'd be very interested if this works for
you, or if you hit any other problems after this point.
Regards,
Roger
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Roger Leigh wrote on 21/06/2017 12:20:
> On 21/06/17 08:48, Vitaly Prapirny wrote:
>> I've got an error while running cmake with "Borland Makefiles"
>> generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?
>
> It's not a combination I've personally tested, but I can't see any
> evidence that it shouldn't work.
>
> What are the errors you are seeing? Maybe it just needs a few minor
> tweaks to our cmake logic.
I've attached log files to the
https://issues.apache.org/jira/browse/XERCESC-2077
Good luck!
Vitaly
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/06/17 08:48, Vitaly Prapirny wrote:
> Roger Leigh wrote on 21/06/2017 09:54:
>> On 21/06/17 02:42, Cantor, Scott wrote:
>>> Are the Xerces_autoconf_config.borland.hpp and
>>> Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think
>>> those are the hardwired versions used in the old builds.
>>>
>>> I don't want to leave them on trunk if they're going to atrophy and I
>>> don't really imagine we'd be doing anything to ensure they worked if
>>> the solution files came from cmake now.
>>
>> Yes, these are only used by the old project files. CMake ignores them
>> entirely, so they can certainly be removed.
> I've got an error while running cmake with "Borland Makefiles" generator
> and Borland C++ Builder 5 compiler. Is BCB5 still supported?
It's not a combination I've personally tested, but I can't see any
evidence that it shouldn't work.
What are the errors you are seeing? Maybe it just needs a few minor
tweaks to our cmake logic.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Vitaly Prapirny <ma...@mebius.net>.
Roger Leigh wrote on 21/06/2017 09:54:
> On 21/06/17 02:42, Cantor, Scott wrote:
>> Are the Xerces_autoconf_config.borland.hpp and
>> Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think
>> those are the hardwired versions used in the old builds.
>>
>> I don't want to leave them on trunk if they're going to atrophy and I
>> don't really imagine we'd be doing anything to ensure they worked if
>> the solution files came from cmake now.
>
> Yes, these are only used by the old project files. CMake ignores them
> entirely, so they can certainly be removed.
I've got an error while running cmake with "Borland Makefiles" generator
and Borland C++ Builder 5 compiler. Is BCB5 still supported?
Good luck!
Vitaly
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 21/06/17 02:42, Cantor, Scott wrote:
> Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds.
>
> I don't want to leave them on trunk if they're going to atrophy and I don't really imagine we'd be doing anything to ensure they worked if the solution files came from cmake now.
Yes, these are only used by the old project files. CMake ignores them
entirely, so they can certainly be removed.
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
Roger,
Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds.
I don't want to leave them on trunk if they're going to atrophy and I don't really imagine we'd be doing anything to ensure they worked if the solution files came from cmake now.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 16/05/2017 19:42, Roger Leigh wrote:
> 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)
I should have mentioned: from an autoconf point of view,
"configure_file" is directly equivalent to "AC_OUTPUT" but with a bit
more flexibility in that the input and output names are explicit and can
differ--no implicit .in extension in the source tree or requirement that
they have the same pathname.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
> 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.
> 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.
No, it was more the overarching set of defines and how they're populated.
> 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.
I'm very unfamiliar with the tests but that all makes sense.
> 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.
> 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.
Oh, I know that, it's the concern that if we don't/can't replace the autotools pieces we end up needing to maintain both to keep the config.h/etc. material in sync and working.
> 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)
> 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...
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.
-- Scott
Re: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 6/3/17, 6:02 PM, "Roger Leigh" <rl...@codelibre.net> wrote:
> I guess there's now always the option of deleting some or all of the
> stuff under projects/Win32 if you wanted to avoid updating the version
> in them all!
Oh, I intended to remove all that. My project's going to be moving up to VC2017 anyway.
-- Scott
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
On 31/05/17 14:23, Cantor, Scott wrote:
> Roger, if you want to check the patch into trunk that's fine. I'm holding off bumping the versions to 3.2 since it will break your current patch and it would be best if I figure out how to get the version bumped in the new Windows builds anyway.
I have now committed the CMake patch as revision 1797546.
I guess there's now always the option of deleting some or all of the
stuff under projects/Win32 if you wanted to avoid updating the version
in them all!
Regards,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Integrating CMake support for xerces
Posted by "Cantor, Scott" <ca...@osu.edu>.
Roger, if you want to check the patch into trunk that's fine. I'm holding off bumping the versions to 3.2 since it will break your current patch and it would be best if I figure out how to get the version bumped in the new Windows builds anyway.
-- Scott
Re: Integrating CMake support for xerces
Posted by Roger Leigh <rl...@codelibre.net>.
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org