use cmake for builds

[GoogleCodeExporter]

The MSVC project is way behind the latest MSVC version, which forces devs on 
windows to do project upgrades, and lots of one-off fixes (for example, #531).

Additionally, building gtest in a project (say as a git submodule) has lots of 
platform-dependent code: if we're on *nix, build it like this, if we're on win, 
build it like this.

protobuf should switch to using CMake so that there's one way to build the 
project.  This will put any msvc issues to bed, and make building the project 
as a submodule trivial.

See gtest for an example of another google project that is successfully using 
CMake.

Original issue reported on code.google.com by paleozogt on 4 Aug 2014 at 5:28

[GoogleCodeExporter]

My understanding is that using CMake will allow us to use one set of build 
configuration files for all platforms so it probably will make it easier to 
maintain.

I don't see the benefit of using CMake from the users' point of view though. 
Even with CMake, users still need to "to build with mingw, run CMake with these 
parameters and make; to build with VC, run CMake with those parameters and open 
the generated sln file". Unless the user already uses CMake in his project, 
using CMake just adds another step to their build process. The sln/vcproj files 
we provide being behind the latest MSVC version doesn't seem a problem to me. 
Upgrading is just one or two clicks. The one-off fixes you mentioned are needed 
any way regardless of whether CMake is used.

Original comment by xiaof...@google.com on 4 Aug 2014 at 8:16

[GoogleCodeExporter]

With CMake you can generically build across platforms with a single command: 
"cmake --build .", which will invoke make/msbuild/nmake/etc as appropriate.  
Surely this is useful even if the users aren't using CMake themselves.

CMake is directly analogous to autoconf, except that its more cross-platform.

"just a few clicks" to get it to work on Windows is a big problem for automated 
builds.  ie, if the user is pulling in gtest as a submodule, or automatically 
downloading/unzipping/building as part of their build.  We've had to internally 
fork protobuf so that it has the upgraded msvc proj files.

Original comment by paleozogt on 4 Aug 2014 at 8:45

[GoogleCodeExporter]

Dear Protobuf developers,
Integrating protobuf vsprojects into a CMake based project, is a big major 
PITA. I have been maintaining code for years doing that and it's one of the 
reason I'm looking at alternatives.

Not only maintenance and pull-requests will be easier to manage if there is 
only one source defining the targets, but it also help most C++ developers 
which either already use CMake or will have no trouble just generating the 
projects for protobuf with cmake, then focus on their specific project files.

You might be seeing the issue in the wrong way: adding a very simple to use 
tool to generate any project file is not at all a burden for the user, except 
if your cmake file don't do their job. It's a very minor addition of tool for a 
major improvement in long-term maintainability and dependency management.

Original comment by mjklaim@gmail.com on 6 Aug 2014 at 9:42

[GoogleCodeExporter]

To complete my argument: I'm using mainly VS and it does not help to have such 
backward projects because each time I want to re-generate from scratch my build 
(for whatever reason it happen every few days or week depending on what I'm 
working on), I have to manually convert teh project files first. It's almost 
impossible to automate.

Original comment by mjklaim@gmail.com on 6 Aug 2014 at 9:44

[GoogleCodeExporter]

Hi paleozogt & mjklaim, thanks for your comments. I think you are right that 
cmake is a better alternative than the vc files we have and it's especially 
useful for build automation. We'll consider adding cmake support after we 
finish the current release (2.6.0) we are working on. In the future we'll make 
new releases more frequently so cmake may also be useful to automate our 
cross-platform test process.

Original comment by xiaof...@google.com on 6 Aug 2014 at 10:59

• Changed state: Accepted

[GoogleCodeExporter]

That's a good news! I think the main pain with CMake is learning exactly how to 
generate non-trivial projects, but as soon as you get it (and it's getting 
easier with each CMake version) it will certainly help a lot with faster 
iterations indeed.

Original comment by mjklaim@gmail.com on 6 Aug 2014 at 11:03

[GoogleCodeExporter]

We're now switching our project to VC12 and I need to recompile protobuf with 
the new VS version. I'm encountering lots of problems with the currently 
provided VS solution.

Is there a time frame for this? It would be SUPER-USEFUL to have a CMake! 
Thanks a lot!!

Original comment by dina...@gmail.com on 2 Oct 2014 at 6:47

[GoogleCodeExporter]

In the meantime, I created a VS2013 solution with both Win32 and x64 
configurations. Two of the test projects didn't compile with a weird message 
about cmd.exe but I didn't care for the tests anyway.
Other than that everything seemed to work for me.

Original comment by dina...@gmail.com on 2 Oct 2014 at 11:27

Attachments:

• vsprojects.7z