+1 Let's move to CMake. It has much better support, and it's not worth maintaining two build systems. If we really want we could maintain a make file which manages the installation of cmake and calls cmake internally! It seems easy to install cmake. There is a shell script with binary for all Linux x86_64, Windows, Mac. For other systems as well, it's just a couple of steps.
Regards, Rahul On Fri, 1 Jun 2018 at 15:12 Chen HY <chenhy12...@gmail.com> wrote: > building for rpi doesn't mean you should build on a rpi... that takes > forever. > > 2018-06-01 23:06 GMT+01:00 Anirudh <anirudh2...@gmail.com>: > > > +1 to using cmake and deprecating Makefile. I was able to find a previous > > discussion on this: > > https://github.com/apache/incubator-mxnet/issues/8702 > > > > The concerns raised were > > 1. Building on devices like raspberry pi where cmake is non existent or > > old. > > 2. Adding an additional dependency. > > > > As mentioned in the thread, if we provide good instructions on how to > > install cmake/build cmake from source, > > these concerns will be addressed. > > > > Anirudh > > > > On Fri, Jun 1, 2018 at 2:58 PM, Alex Zai <aza...@gmail.com> wrote: > > > > > Just realized that the email lists strips aways all hyperlinks. > Attached > > > is a > > > copy of my previous email with links pasted in. > > > > > > What are peoples' thought on requiring cmake when building from source? > > > Currently we have to maintain two independent build files (CMakeLists > and > > > Makefile) which makes it more difficult to develop (each are 600+ > lines). > > > Also, > > > our current build system (in Makefile) requires that 3rdparty > > dependencies > > > have > > > binaries present (or a Makefile to generate binaries) in the repo, > which > > > is not > > > always the case. > > > Generating a makefile with cmake will make our Makefile very simple > like > > > PyTorch'sMakefile (20 lines of code - > > > https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not > all > > > 3rdparty > > > dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up > > > calling > > > cmake > > > (https://github.com/apache/incubator-mxnet/blob/master/ > > > prepare_mkldnn.sh#L96) > > > to generate binaries (this does not violate our 'no cmake dependency' > as > > > USE_MKLDNN is OFF by default). If we encounter any library in the > future > > > that > > > requires us to generate artifacts with cmake, it would be better to > make > > > the > > > switch now. Lastly, we already require cmake as a dependency > forwindows' > > > developers > > > (https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot% > > > 202018-06-01%2013.43.08.png?dl=0) > > > so this would only affect linux / mac developers who do not have cmake > > > already. > > > I currently have a pendingPR > > > (https://github.com/apache/incubator-mxnet/pull/11118/) that depends > on > > > this > > > change. The library does not have a Makefile or binaries present. > Unlike > > > mkldnn, > > > we would want this library included by default so I cannot generate > > > artifacts > > > with cmake. The alternative would be to strip out only the relevant > parts > > > of the > > > code we need from the library. I did this in a previous version of myPR > > > (https://github.com/apache/incubator-mxnet/compare/ > > > dfdfd1ad15de8bb1b899effb0860a4e834093cfc... > > a4267eb80488804a7f74ff01f5627c > > > 47dd46bd78) > > > but it is incredible messy. > > > Please let me know your thoughts. > > > Best, > > > Alex > > > > > > > > > > > > > > > > > > On Fri, Jun 1, 2018 2:51 PM, Alex Zai aza...@gmail.com wrote: > > > What are peoples' thought on requiring cmake when building from source? > > > Currently we have to maintain two independent build files (CMakeLists > and > > > Makefile) which makes it more difficult to develop (each are 600+ > lines). > > > Also, > > > our current build system (in Makefile) requires that 3rdparty > > dependencies > > > have > > > binaries present (or a Makefile to generate binaries) in the repo, > which > > > is not > > > always the case. > > > Generating a makefile with cmake will make our Makefile very simple > like > > > PyTorch's Makefile (20 lines of code). Also, not all 3rdparty > > dependencies > > > have > > > binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake to > > > generate > > > binaries (this does not violate our 'no cmake dependency' as USE_MKLDNN > > is > > > OFF > > > by default). If we encounter any library in the future that requires us > > to > > > generate artifacts with cmake, it would be better to make the switch > now. > > > Lastly, we already require cmake as a dependency for windows' > > > developers so this > > > would only affect linux / mac developers who do not have cmake already. > > > I currently have a pending PR that depends on this change. The library > > > does not > > > have a Makefile or binaries present. Unlike mkldnn, we would want this > > > library > > > included by default so I cannot generate artifacts with cmake. The > > > alternative > > > would be to strip out only the relevant parts of the code we need from > > the > > > library. I did this in a previous version of my PR but it is > incredible > > > messy. > > > Please let me know your thoughts. > > > Best, > > > Alex > > > > > > > > > -- > Chen Hanyang 陈涵洋 > Software School Fudan University > +86-138-1881-7745 <+86%20138%201881%207745> >
