zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From andschwa <...@git.apache.org>
Subject [GitHub] zookeeper issue #306: ZOOKEEPER-2841: ZooKeeper public include files leak po...
Date Sat, 08 Jul 2017 23:16:32 GMT
Github user andschwa commented on the issue:

    @hanm the PR is rebased, retested, and has some extra notes in it now for some weird CMake
    I would not put the CMake files in a separate folder. There are couple of reasons for
    * 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 infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message