Request - switch to CMake as the only build system

[lukeyeager]

Motivation

• Keeping up with two build systems is a hassle and is prone to errors and discrepancies.
• Potential contributors may be scared off by having to figure out how to make their code build with both systems.
• Switching to a single build system would let us cut the number of TravisCI builds in half.

Questions

1. What else needs to be done before the CMake build can be considered "full featured"?
2. What would the implications be of deleting the manual Makefile build system? Who would be unhappy?
3. If the community pitched in to address issues from (1) and (2), would the Caffe devs be willing to commit to CMake and delete the manual Makefile build system entirely?

Background

@Nerei contributed a major CMake upgrade in #1667, but it was decided to keep the old manual Makefile build around.

The official Makefile and Makefile.config build are complemented by an automatic CMake build from the community.
https://github.com/BVLC/caffe/blob/603cbfb977/docs/installation.md

Several community members have requested that we move to a single build system (especially the ever vocal @bhack):

As I stated some month ago when cmake was introduced in caffe it is better to support only one build system to avoid divergence between make tools and cmake and to not duplicate community and core members efforts to maintain two build systems.
@bhack #1738 (comment)

Or probably remove Makefile. Two build system are quite impossible to be maintained in sync. Also Travis builds are not aligned between Make and Cmake.
@bhack #2651 (comment)

I believe that Makefile should die from a point, nobody will update it. CMake should overtake as primary build configurator / manager. By the way CMake in contrast with autoconf/automake and Make saga enable us to be cross-platform too.
@cbalint13 #3311 (comment)

Here are some comments from the Caffe devs about Make vs. CMake:

The core developers are responsible for the Makefile build, but the CMake build is currently developed by the community until it is full featured so please do improve it.
@shelhamer #1586 (comment)

I have no more time to play with build systems, I'm going back to Makefile. I'd love to have a single, beautiful, clean and readable, automagic build that works for everybody, but this is exactly what I feared: the build goes wrong, and then I have to dig. My impression is that this is a big improvement over the previous CMake build, and we should probably merge it, though I'll leave that up to others, but I can't yet support making this the one true build.
@longjon #1667 (comment)

As an improvement to the current CMake build this is a step forward, but still short of an official build. This should likely be merged for those it does help, but at the same time there are many who can't have their work hampered by a byzantine build, so the official Makefile is still needed in that role.
@shelhamer #1667 (comment)

[bhack]

📣 "especially the ever vocal"

[lukeyeager]

My list of CMake TODOs:

Must have

• None?

Nice to have

• Build tests as separate executables, like the Makefile build does
• Improve the layout for cmake-gui to group options by folders in the style of OpenCV:
  

[flx42]

I think we need an equivalent to CUDA_ARCH from Makefile.config. All the necessary blocks are apparently here, for instance the following works:

$ cmake -DCUDA_ARCH_NAME=Kepler .

[cbalint13]

@lukeyeager ,

Permit me touch release engineering water a bit more:

• If this motion pass and we also have some version tag and crucial soversion support for shared lib caffe Add library versioning and mark version 1.0.0-rc3 #3311 I would take my time and try propose/contribute/promote some nice .spec file that leads to implicit packages for fedora/rhel products. We can even further pass to official upstream Fedora / Rhel-Extras as regular builds. I believe it would have a nice place within their official SciTech: https://fedoraproject.org/wiki/SIGs/SciTech/PackageList.
• Other folks could try Ubuntu, Debian too (I don't know those distros too much), but i am sure at a point someone from their community sooner or later will pick caffe up and push it into mentioned distros.
• I am sure official binaries (preferable on distro upstream side) would ease life for many people. We also can take the advantage of arm, sparc, powerpc arches that vast majority of distros maintains too.
• Once pushed to their upstream the very distros infrastructure and their community will take further care to sync with caffe latest releases, little has do be done from caffe side, anyway they will complain with PR here at very caffe if builds goes wrong.

Hope to mention these release-engineering aspects with proper timing here.

[cbalint13]

@flx42 ,

• Your proposal already exists and works for caffe's cmake (at least for me):

$ cat ~/rpmbuild/SPECS/caffe.spec | grep Auto
       -DCUDA_ARCH_NAME="Auto" \

• On my desk "Auto" detects my very card maximal capability. All is already done in Cuda.cmake:

cat ~/rpmbuild/BUILD/caffe/cmake/*.cmake | grep Auto
    message(STATUS "Automatic GPU detection failed. Building for all known architectures.")
    list(APPEND __archs_names "Auto")
    set(__archs_name_default "Auto")
  elseif(${CUDA_ARCH_NAME} STREQUAL "Auto")
# Automatically align right column and selects text based on condition.

• And e.g "Kepler" or "Maxwell" works too:

$ cat ~/rpmbuild/BUILD/caffe/cmake/*.cmake | grep Kepler
  set(__archs_names "Fermi" "Kepler" "Maxwell" "All" "Manual")
  elseif(${CUDA_ARCH_NAME} STREQUAL "Kepler")

[flx42]

@cbalint13 Uh, yes, that's exactly what I said, but the option is hidden.

[bhack]

@cbalint13 See @cdluminate work at #2601

[cdluminate]

IMHO if you are going to set CMake as the only build system,
please make sure the frequently used variables are nicely documented,
e.g. CUDA_ARCH_NAME as above.

I wrote working packaging files for debian (debian/rules), after reading all the CMakefiles.
However we can't expect users to read all CMakefiles to see what the options are.

As refered in #2601, the variables I overrode are recored in the debian/rules file,
and I suggest that these options should be documented:

-DBLAS="Open" \
-DCPU_ONLY=ON \
-DUSE_CUDNN=OFF \
-DBUILD_python=ON \
-Dpython_version="2" \
-DBUILD_matlab=OFF \
-DBUILD_docs=OFF \
-DBUILD_python_layer=ON \
-DCUDA_ARCH_NAME="All" \

-DCMAKE_CXX_COMPILER=g++-4.9    # this is CMAKE VAR but will be useful for user to switch compiler
-DCMAKE_C_COMPILER=gcc-4.9        # this is CMAKE VAR but will be useful for user to switch compiler

Maybe we can change Makefile and Makefile.config into CMake wrapper, i.e.

• Makefile.config

BLAS=Open
VAR2=...

• Makefile

include Makefile.config
CONFIG= -DBLAS=$(BLAS) -DVAR2=$(VAR2) ...

main:
    cmake <dir> $(CONFIG)
    make <options> -C <dir>

[antran89]

Another support from me. With CMake, Caffe project can be easily imported to QtCreator to view code, edit, develop further.

[bhack]

Caffe binary packaging could be also organized with Cmake Cpack Generators for Windows/Linux/OSX

[jyegerlehner]

I agree with switch to CMake. It's the only one I use. Doesn't everyone want out-of-source builds? No idea what is regarded as deficient about it. I also use qtcreator and its support for CMake in order to debug efficiently.

[ronghanghu]

I also support using only one build system instead of two, and CMake offers more compatibility than the raw Makefile.

But I would like to wait and hear other people's opinions before making any changes. @shelhamer @jeffdonahue @longjon what do you think of this?

[liquidmetal]

Cmake can figure out the correct dependencies for the project based on the OpenCV version (need to add -lopencv_imgcodecs for OpenCV 3). The main Makefile can't do this yet (it requires explicitly setting the variable OPENCV_VERSION. This adds another con to maintaining the Makefile.

[shelhamer]

Improvements to CMake are always welcome and it has proven popular with the community. Making it the One True Build demands a high standard.

1.What else needs to be done before the CMake build can be considered "full featured"?

It's not purely a matter of features, although it is necessary to be complete w.r.t. to the Makefile, but a matter of order and care. The build should be modular (not copy-paste), configurable (not hard-coded), and organized (arranged by purpose, like grouping Python options, and commented to explain).

Right now there are hardcoded references to OS X 10.9, Boost 1.46, and potentially other platforms/packages/versions without explanation. The Makefile, while bespoke, is careful to check platform versions and adapt accordingly with comments for reasons as in https://github.com/BVLC/caffe/blob/master/Makefile#L269-L300. However I'll be the first to admit it is not perfect, and for instance does not handle OpenCV versions automatically and there's a lurking python2.7 reference.

Of course the Makefile or CMake custom build logic can break, which is an argument for having a unified build so we can all collaborate on having the right logic.

The CMake build is ~4x the code of the Make build. Granted it has more responsibilities, but this seems a bit much.

2.What would the implications be of deleting the manual Makefile build system? Who would be unhappy?

The Makefile is the official build and relied on by the core in the BVLC. Until the CMake build suffices for our dev workflow and our research and dev machines -- with Ubuntu 14.04, 15.04, 16.04 and OS X 10.{9,10,11} and CUDA 7.5 (and back to 6.0) -- the Makefile will persist.

3.If the community pitched in to address issues from (1) and (2), would the Caffe devs be willing to commit to CMake and delete the manual Makefile build system entirely?

We're happy to merge work improving the CMake build, and don't see the Makefile as an obstacle to this. Should it reach the point that it's reliable, orderly, and transparent enough to convince the core devs to switch then it sounds like it would be a candidate for the sole build.