[DISCUSSION] Should we deprecate Makefile and only use CMake?

[piiswrong]

1. Maintaining two build pipelines has been a lot of trouble.
2. We are planning to pull in dependencies and build/link them together with MXNet, similar to what we are doing with the pip package. CMake is better suited for this.

@cjolivier01 @yajiedesign @szha

[yajiedesign]

+1 CMake is better

[cjolivier01]

+1 for CMake

On Fri, Nov 17, 2017 at 6:57 PM Hu Shiwen notifications@github.com wrote:

+1 CMake is better

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/incubator-mxnet/issues/8702#issuecomment-345413447, or mute the thread https://github.com/notifications/unsubscribe-auth/AKts_e_USF5GrueCBsV17MLFmvhnYoTuks5s3keBgaJpZM4Qiy9z .

[szha]

+1 for cmake. On specifics:

1. while we can provide the option to statically link dependencies, how to bring in dependencies is still the concern of a user. So the option of linking shared objects or specifying a search path should be supported by cmake. OpenCV and a number of other packages does it.
2. I haven't had enough experience in using cmake in mxnet to make a call on whether all use cases are supported in our cmake file. I know for sure that the makefile has served me well. So I'd suggest that during transition we only add new options to cmake while still maintaining makefile for the old options, until there's enough confidence in cmake.

[cjolivier01]

I am not aware of any build option that CMake doesn’t support — I’ve been keeping it current. At this point, I think it has more features than Makefile. If there is something missing, it’s an outlier and I haven’t run into it but it could be added quickly.

As for submodules, I think some we’d tend to want some of them to be part of a recursive clone, such as OpenMP — it’s small and they payoff for using it instead of gcc’s version is high.

[piiswrong]

One potential problem is it adds another dependency. Its particularly painful for people using centos or redhat

[cjolivier01]

One potential solution would be a script (python or bash) that fetches, builds and installs CMake. An AMI that we are all familiar with does this. It could be run on any platform if it’s python.

On Fri, Nov 17, 2017 at 10:42 PM Eric Junyuan Xie notifications@github.com wrote:

One potential problem is it adds another dependency. Its particularly painful for people using centos or redhat

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apache/incubator-mxnet/issues/8702#issuecomment-345422711, or mute the thread https://github.com/notifications/unsubscribe-auth/AKts_bu7Ig1KCoDMjHnTTcWa9ifVK_Gpks5s3nxxgaJpZM4Qiy9z .

[yajiedesign]

@szha shared or static opencv depends on how user provide opencv.the opencv also use cmake build system and include "OpenCVConfig.cmake",this makes it easy for other cmake projects to refer to it.

[yuewu001]

+1 cmake, especially for cross platform

[tqchen]

CMake is great, and we can still use the configuration based tricks https://github.com/dmlc/tvm/blob/master/CMakeLists.txt#L10 to rely on a config.cmake to customize the build option.

We might want to leave simple rules like lint to Makefile (or as a python script) since it does not really help to bring them to cmake. The only problem we might see is it increases the burden on build on embedded systems like raspberry Pi where CMake version is not great. Could be resolved by adding clear instruction to build cmake from source.

[cjolivier01]

btw, CMake has the lint stuff, or more likely, a partial/outdated version of it. Targets are mxnet_lint, dmlc_lint, mshadow_lint.

I also have CMake packages in another project I've made to do gcov analysis that I could pull in and maybe help the local infra ppl to add to this project.

[larroy]

+1 for CMake

[larroy]

@piiswrong CMake has become the de-facto standard to build C/C++ projects. Seems installing in those platforms is just make && make install. But indeed is an additional dependency, but Make is a separate program as well. Why do you say it's painful? the CMake installation doesn't seem too complex.

[yajiedesign]

@cjolivier01 yes, lint is out of date,but fix it not difficulty .