[
https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861392#comment-15861392
]
James E. King, III commented on THRIFT-4037:
--------------------------------------------
There are many reasons to switch to cmake. Many other open source projects
like libevent and zlib have done so in their master branch.
cmake generates out-of-tree builds, for one. I haven't seen a way to do this
with configure (yet). If there is a way please let me know because I really
don't like in-tree builds. Building openssl on windows is currently a strange
perl based exercise instead of autoconf. If openssl used cmake they would have
a single build system for all supported platforms as well.
cmake gives you cross-platform capabilities that autoconf does not, for example:
cmake can generate visual studio projects, eclipse projects, nmake scripts,
ninja scripts, etc.. this is nice because you can work in your favorite IDE
more easily or use command line scripts.
cmake -G"Eclipse CDT4 - Unix Makefiles"
cmake -G"Visual Studio 14 2015 Win64"
cmake -G"NMake Makefiles"
cmake -G"MinGW Makefiles"
cmake -G"Ninja"
then run "cmake --build ." to build using whatever it is.
You can configure cmake the same way as autoconf to enable and disable features
of thrift:
cmake -DWITH_PERL=OFF -DWITH_PYTHON=ON (etc)
see build/cmake/DefineOptions.cmake
autoconf hasn't been updated since 2012 based on my inspection of the gnu ftp
server, which worries me a bit. No software is ever done, is it still being
actively developed?
The biggest problem on windows is the third party libraries and the runtime
link options, which cmake won't solve:
* You have to choose static or dynamic runtime linking
* You have to build all the third party libraries the same way
* If you want to make a DLL you have to "export everything" or annotate your
code with declspec dllexport statements
I'm a big fan of cmake, I'll admit, and it may not do everything out of the box
but it does a lot and you can extend it pretty easily. The conversion started
on this project a number of years ago by other folks and it will take a while
to complete. This is why we're not deleting the autoconf build any time soon.
As for the c_glib use of autoconf, it may still use that. Note the java build
under autoconf and under cmake for this project both farm out to ant. There's
no one build system that solves all. I find cmake much easier to use and more
flexible for developers on multiple platforms.
What I do see in your message is a warning of the use cases we need to continue
to support and it sounds like you use thrift extensively in your project(s)
which we love to hear. I would like to capture all of your concerns as
acceptance criteria for making the conversion, for example "Support
cross-compilation", "Support Mac". How about, "Support Android", "Support
iPhone" as well? Mac is missing in our CI environment as well which is a gap.
Sometime in the future I hope we can move everything to a single build system
that properly supports all the platforms and languages and would like to work
with everyone to realize that, but it's going to take time and until we know it
works, the autoconf system will be available.
> [CMake] As a developer, I want to use a single build system for thrift to
> make development easier
> -------------------------------------------------------------------------------------------------
>
> Key: THRIFT-4037
> URL: https://issues.apache.org/jira/browse/THRIFT-4037
> Project: Thrift
> Issue Type: Epic
> Components: Build Process
> Affects Versions: 0.10.0
> Environment: All
> Reporter: James E. King, III
> Assignee: James E. King, III
> Priority: Critical
>
> h1. Background
> The thrift project currently carries two build systems. The original build
> system is based on autoconf and is used to build a complete deliverable
> including extensive cross-language testing.
> The other build system was introduced a few years ago, with roots tracing
> back to THRIFT-797. CMake allows thrift to build natively on multiple
> platforms - unix and windows. Autoconf is no longer under active development
> with the last release in 2012, and it does not allow for native windows
> builds using native tools that are used by a majority of consumers.
> Maintaining two build systems for a project incurs a lot of overhead. Every
> change that touches the build system needs to be done twice, in two
> completely different ways. We need twice as many CI jobs to verify that all
> of the builds are working, whereas with a single cmake build environment we
> could likely use a single CI build job per platform that does everything
> using the docker image on linux and appveyor on windows.
> h1. Proposal
> We should officially deprecate autoconf in favor of cmake, and continue (more
> aggressively) the effort to make the cmake build environment as functional as
> the autoconf build environment. During this transition, folks will be
> required to make changes to both build systems (which are proven out mostly
> through the Travis CI build jobs; only CMake is used on AppVeyor).
> h1. Acceptance Criteria
> # autoconf build environment is removed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
