> 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
