Agree. Having two build systems to maintain will become a PITA quickly.
Everything that is easier and more reliable than autotools (I'm looking at
you, MinGW) gets a +1 from me. As I understand it, the Visual Studio
project(s) will still be available somehow, right?
JensG
-----Ursprüngliche Nachricht-----
From: Jake Farrell
Sent: Monday, November 24, 2014 11:04 PM
To: dev@thrift.apache.org
Subject: Re: [DISCUSS] CMake for Apache Thrift
I do not think that we should run both autotools and cmake in parallel.
There are enough pieces that get missed when new client libraries or files
are added that make putting the releases together harder than they need to
be without having to make sure that its mirrored into an additional build
system.
Switching to cmake has been proposed before, THRIFT-797, and at that time
there was little benefit to switching away from autotools. As we now
support a lot more clients libraries and autotools has had a tendency to
break backwards compatibility perhaps this might be a good time to look at
overhauling the build to make things easier.
-Jake
On Mon, Nov 24, 2014 at 3:36 PM, Roger Meier <ro...@bufferoverflow.ch>
wrote:
Hi all
The Apache Thrift compiler is optionally using CMake already and we had
very good experience by using CMake also for the cpp library to get it up
and running on Linux-ARM, Linux-x86, Windows CE and Windows.
I like to propose CMake as an additional build system for Apache Thrift.
Goal: Extend Apache Thrift's *make cross* approach to the build system.
Due to growing field of operating system support, a proper executable
and library detection mechanism running on as much platforms as possible
becomes required. The other aspect is simplify the release process and
package generation process.
As nice side benefit of CMake is the generation of development environment
specific solution files(VisualStudio, Eclipse, Xcode, etc. ).
=> No solution files within source tree.
see https://issues.apache.org/jira/browse/THRIFT-2850
What are your thoughts?
all the best!
-roger
