Remove Makefile.config build completely.

[de-vri-es]

This PR removes the Makefile.config based build system completely. Maintaining two different build systems is extra maintenance overhead that I think the project can do without.

Given the choice between a hand crafted Makefile and CMake, I think CMake is a much better alternative. It is widely used by a very large number of projects, and because of that well understood by both open source developers and distro packagers.

I also updated the documentation where it referred to the Makefile build.

edit:
As an added bonus the number of travis tests is reduced to half.

[naibaf7]

I don't think it should be removed. It's very much more convenient than CMake for developers of Caffe like me during development and testing... also the CMake system in it's current state is still very cluttered and messy, and needs improvement.

[de-vri-es]

It's very much more convenient than CMake for developers of Caffe like me during development and testing...

I disagree. The overhead of running the following commands once before building is pretty negligible:

mkdir build
cd build
cmake .. -Dopt=val

You can even put that in a script so you don't have to manually type the options if you do a clean configure. Such a script would be the equivalent of the current Makefile.config. Also note that cmake automatically reconfigures when you run make if you changed the CMakeLists.txt.

As developer you now have to maintain both build systems, and keep them in sync with each other. That is much more of a problem than having to do a configure step once before building.

also the CMake system in it's current state is still very cluttered and messy, and needs improvement.

Can you give more specific feedback? I'll happily clean it up if that means reducing the number of build systems to 1.

[naibaf7]

First off, due to quirks between the Windows, OpenCL and Main branch, those are not convergent in the CMake system at the moment, because every branch has had another "refactoring" to improve it. Merging changes between those is more painful than necessary. So at first, it would have to be sorted out how to fix that. The Makefile was more stable in that regard, since it was used with OS X and Linux only. I am also not sure how much testing was done with the CMake under OS X.

Installation routines with CMake do not work well at the moment. Dependencies may be broken, especially with regards to the "proto" target and the "python" target.
There are some dissonances with regards to the caffe_config.h.in, see: #4609 and "most of the dependencies are made PUBLIC", which has subsequently been broken again by the windows branch, for example.
This then led to the following issue:
#5378
Which was only possible to fix applying this:
7b0bafd
basically reverting a part of #4609.
But this is just the most recent messup example.

Lastly the Makefile is currently used in production environments, so removing that compile path would be a bit disruptive for current users.

If that's all cleaned up, I'll happily approach the other maintainers for a quick(er) merge.

[de-vri-es]

First off, due to quirks between the Windows, OpenCL and Main branch, those are not convergent in the CMake system at the moment, because every branch has had another "refactoring" to improve it. Merging changes between those is more painful than necessary.

Good point. I think this is caused in large part by keeping Windows and OpenCL support in different branches. The easiest way to make sure there are no annoying cross-branch sync issues is by not having long lived branches. How would you feel about providing Windows and OpenCL support in the master branch (which undoubtedly requires some work)?

Installation routines with CMake do not work well at the moment. Dependencies may be broken, especially with regards to the "proto" target and the "python" target.

We've successfully used the cmake build to package Caffe for Arch Linux with little trouble. We required only minor changes to use python3 instead of python2. Nevertheless, I did indeed notice a few quirks in the cmake system that could be improved.

Lastly the Makefile is currently used in production environments, so removing that compile path would be a bit disruptive for current users.

This is of course true, but especially for deployment systems (as opposed to development systems) cmake is far easier to use. A migration guide (or section in current build docs) could be added detailing how to switch to the cmake system from the old Makefile system. It wouldn't have to be that long as it is relatively straightforward (basically: replace options in Makefile.config with -D flags to cmake).

[naibaf7]

Sure, it would be about time to have mainline support for OpenCL and Windows (those are also the most active branches in development), but I don't think it's a realistic goal at the moment, unfortunately. But at least the build system should be solid for all three branches in my opinion, if it's going to be CMake only.

[willyd]

@naibaf7 Thanks for pointing out the issue on the windows branch. I have yet to integrate those changes to in the windows branch so it is good to know in advance. I will let you know when they are properly fixed.

[hgaiser]

I agree that having two build systems to maintain is much more inconvenient for developers than the benefits of being able to choose between two build systems. I would be very much in favor of moving towards one build system, for which CMake would be the most logical choice in my opinion. I completely understand if there is dissatisfaction with the current CMake build system, but I think it is important to address those issues (or if necessary do a complete/partial rewrite). If a solution like this (CMake rewrite) would be accepted by the Caffe developers then I would like to know so that I or someone else can contribute by making a PR for that.