mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Zai <aza...@gmail.com>
Subject Re: Make cmake default
Date Fri, 01 Jun 2018 21:58:07 GMT
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...a4267eb80488804a7f74ff01f5627c47dd46bd78)
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