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