From dev-return-2989-archive-asf-public=cust-asf.ponee.io@mxnet.incubator.apache.org Mon Jun 4 09:43:33 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4B756180674 for ; Mon, 4 Jun 2018 09:43:33 +0200 (CEST) Received: (qmail 39794 invoked by uid 500); 4 Jun 2018 07:43:32 -0000 Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mxnet.incubator.apache.org Delivered-To: mailing list dev@mxnet.incubator.apache.org Received: (qmail 39734 invoked by uid 99); 4 Jun 2018 07:43:31 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2018 07:43:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 11CCC180188 for ; Mon, 4 Jun 2018 07:43:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.899 X-Spam-Level: ** X-Spam-Status: No, score=2.899 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.de Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id jEj9LHHj37un for ; Mon, 4 Jun 2018 07:43:27 +0000 (UTC) Received: from sonic301-20.consmr.mail.ir2.yahoo.com (sonic301-20.consmr.mail.ir2.yahoo.com [77.238.176.97]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 9021A5F580 for ; Mon, 4 Jun 2018 07:43:26 +0000 (UTC) X-YMail-OSG: OSTDQNUVM1mI4_miH.MfI3THuZl599H40wFNqyh6Y7iF1Zvud6q8RpTZ01NzbNP GE_ZgRzoruZguSTGv3tsf8KM4Y1B9fHIhnKJMOcx0lgaM9QYiCrfw2f40d6IbRolDFFISX4wwspj L0hU3SHS1xXXwX4rLRr_Iza2OvZh3wP8.KQbojQR_nplfr2EelLMWD15IvesHPGCbIy0u248Dnwz gQWGFDpdI7LxSfrbj6VitFQWGcTZRImpI3AqjUw8ummTNW62xws2Le6Gw6jOWMaAkPZmF06C93ff v_MGeztDzqTZDTSoaQz52uIb1m9OfWFiEmnR3KgL2lt_Y.Edw1cQz8cENUHz4X5oAZRFNneDvYIp NihdbSCX1Bzbf27BFmXfR3ZganfztryeT2fUQ4L6qBZsMxnwqY8v5jm5LH3tGTkVXN_1dj5n5dfl Djz55ySYOEU..ChI1uM2OCvYShZi_mAjpGLQZwlsjt9qiw5XkdbhsSXfeW2TFP66pSbghUlkRjcA f9SXeI6jG2I56K75B1uF4GLvgEOm6Di4lBhcV03jhD3juvpZ64m74QrE5tR77DstPUj36a2akBpW d32ISvxOEIzMzQw6D8_sFDVDv9uGe6Xu4hNKKzqUYWB6Rm3bGMOPA1viYfuRJesCgHVXBVycK2xA qYVE3Am7WQaTBgLbOw3n3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Mon, 4 Jun 2018 07:43:26 +0000 Date: Mon, 4 Jun 2018 07:43:25 +0000 (UTC) From: Asmus Hetzel To: dev@mxnet.apache.org, Message-ID: <1931028260.14545704.1528098205255@mail.yahoo.com> In-Reply-To: <5fc87924-bdd4-bd16-2d6d-12265d3a2fb6@mixmax.com> References: <82add2f1-38d5-6f16-3e62-131e8c3baa84@mixmax.com> <5fc87924-bdd4-bd16-2d6d-12265d3a2fb6@mixmax.com> Subject: Re: Make cmake default MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14545703_150889889.1528098205253" X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Firefox/52.0 ------=_Part_14545703_150889889.1528098205253 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I have dealt with the make/cmake stuff when integrating lapack/cusolver. Ha= ving a single cmake would have made things far easier. Asmus Am Freitag, 1. Juni 2018, 23:58:17 MESZ hat Alex Zai = Folgendes geschrieben: =20 =20 Just realized that the email lists strips aways all hyperlinks. Attached i= s 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). A= lso, 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=C2=A0(20 lines of code - https://github.com/pytorch/pytorch/blob/master/Makefile). Also, not all 3rd= party dependencies have binaries or Makefiles. For 3rdparty/mkldnn we end up call= ing cmake =C2=A0(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 th= at requires us to generate artifacts with cmake, it would be better to make th= e switch now. Lastly, we already require cmake as a dependency forwindows' developers =C2=A0(https://www.dropbox.com/s/9sfnderg58z4j1l/Screenshot%202018-06-01%20= 13.43.08.png?dl=3D0) so this would only affect linux=C2=A0/ mac developers who do not have cmake= already. I currently have a pendingPR =C2=A0(https://github.com/apache/incubator-mxnet/pull/11118/) that depends = on this change. The library does not have a Makefile or binaries present. Unlike mk= ldnn, we would want this library included by default so I cannot generate artifac= ts with cmake. The alternative would be to strip out only the relevant parts o= f the code we need from the library. I did this in a previous version of myPR =C2=A0(https://github.com/apache/incubator-mxnet/compare/dfdfd1ad15de8bb1b8= 99effb0860a4e834093cfc...a4267eb80488804a7f74ff01f5627c47dd46bd78) but it is incredible messy. Please let me know your thoughts. Best, Alex=C2=A0=20 On Fri, Jun 1, 2018 2:51 PM, Alex Zai azai91@gmail.com=C2=A0 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). A= lso, 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=C2=A0(20 lines of code). Also, not all 3rdparty dependen= cies have binaries or Makefiles. For 3rdparty/mkldnn we end up calling cmake=C2=A0to = 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=C2= =A0so this would only affect linux=C2=A0/ mac developers who do not have cmake already= . I currently have a pending PR=C2=A0that depends on this change. The library= does not have a Makefile or binaries present. Unlike mkldnn, we would want this libr= ary included by default so I cannot generate artifacts with cmake. The alternat= ive 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=C2=A0 but it is incredib= le messy. Please let me know your thoughts. Best, Alex =20 ------=_Part_14545703_150889889.1528098205253--