cmake can generate vcxproj files from it's CMakeLists.txt (not sure if that requires something specific on CMakeLists part). So Visual Projects could be removed from repo and generated for example as part of release. (Keeping them now in repo really makes at leats 3 separate build systems to maintain... - for compiler only).

With cmake we could think about releasing thrift.exe using visual, which would remove dependency on mingw.

-KG

W dniu 2014-11-25 o 00:46, Jens Geyer pisze:

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






Reply via email to