Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

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

Open
piiswrong opened this issue Nov 18, 2017 · 13 comments
Open

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

piiswrong opened this issue Nov 18, 2017 · 13 comments

Comments

@piiswrong
Copy link
Contributor

  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
Copy link
Contributor

+1 CMake is better

@cjolivier01
Copy link
Member

cjolivier01 commented Nov 18, 2017 via email

@szha
Copy link
Member

szha commented Nov 18, 2017

+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
Copy link
Member

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
Copy link
Contributor Author

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

@cjolivier01
Copy link
Member

cjolivier01 commented Nov 18, 2017 via email

@yajiedesign
Copy link
Contributor

yajiedesign commented Nov 18, 2017

@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
Copy link

+1 cmake, especially for cross platform

@tqchen
Copy link
Member

tqchen commented Nov 19, 2017

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
Copy link
Member

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
Copy link
Contributor

larroy commented Nov 19, 2017

+1 for CMake

@larroy
Copy link
Contributor

larroy commented Nov 19, 2017

@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
Copy link
Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants