mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen HY <chenhy12...@gmail.com>
Subject Re: Make cmake default
Date Mon, 04 Jun 2018 08:17:34 GMT
glad to hear mxnet.js is back again.

2018-06-04 8:43 GMT+01:00 Asmus Hetzel <asmushetzel@yahoo.de.invalid>:

>  +1
>
> I have dealt with the make/cmake stuff when integrating lapack/cusolver.
> Having a single cmake would have made things far easier.
>
> Asmus
>
>
>
>     Am Freitag, 1. Juni 2018, 23:58:17 MESZ hat Alex Zai <azai91@gmail.com>
> Folgendes geschrieben:
>
>  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
>



-- 
Chen Hanyang 陈涵洋
Software School Fudan University
+86-138-1881-7745

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