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
