mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haibin Lin <haibin.lin....@gmail.com>
Subject Re: Make cmake default
Date Fri, 01 Jun 2018 22:11:32 GMT
+1

Thanks for bringing this up. Maintaining two build systems is a pain.

If we decide to make cmake default, please make sure all installation
documentations are updated correspondingly. They're currently all using
"make" if installed from source.

Best,
Haibin

On Fri, Jun 1, 2018 at 3:06 PM, Anirudh <anirudh2290@gmail.com> wrote:

> +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 <azai91@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 azai91@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message