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:

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 

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,

To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Reply via email to