Github user andschwa commented on the issue:
https://github.com/apache/zookeeper/pull/306
@hanm the PR is rebased, retested, and has some extra notes in it now for
some weird CMake things.
I would not put the CMake files in a separate folder. There are couple of
reasons for this:
* It is a very strong convention with CMake that the top level
`CMakeLists.txt` file exists at the top level of the source directory (thus
making variables like `CMAKE_SOURCE_DIR` make sense). This is also necessary
for the macro `ExternalProject_Add` to be used with older (pre 3.8) versions of
CMake, when it didn't have the `SOURCE_SUBDIR` option. (This macro is often
used by other projects, e.g. Mesos, to download and build a dependency.)
* The CMake system can also be used on Linux platforms (in fact, it's even
setup to build and run the tests with `ctest`). If `cmake` has not been
invoked, or if `autoconf`/`configure` have not been invoked, they will not
interfere with each other (so the source files themselves can co-exist). It's
only the generated files, and only on systems that use `make`, that may become
confusing. But this confusion is easily cleared up by asking: which configure
system did you invoke? So I don't think it'll be much of a problem. (We have
both Autotools and CMake concurrently in Mesos, with the eventual plan of
deprecating the former with the latter. Developers still using Autotools have
been just fine ignoring CMake.)
* CMake can easily build out-of-tree. I've tested this, as I usually build
with `mkdir build; cd build; cmake ..; cmake --build .`. So you can use the
Autotools and CMake systems concurrently, if you're, say, testing both systems.
> Ultimately we might drop existing makefiles in favor of the CMake
That would be fantastic :smile:
The only annoying thing is that, until that day, there are now two systems
to maintain. I'd posit that this is better than the previous situation where
there was the Linux system, and then at least, what, three? Windows systems
being (not) maintained. If (when) CMake does get broken on Linux because a
change was made to Autotools and not replicated to CMake, it won't be the end
of the world. You'll have one working system, and someone (like me) will end up
fixing the other system. Not the greatest situation, but not the worst.
So all that said, leaving CMake available for both operating systems I
think is the right thing to do. The scope of impact is still only on Windows,
as we're deprecating (deleting) the previous build files, and we're adding a
choice for Linux developers. (When ZooKeeper 3.5.3 is released, I'll replace
Mesos's if/else code to build ZK on Linux and Windows with a _single_ piece of
code, using CMake. It'll be awesome.)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
