From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id C2A1E8E7B for <dev@dpdk.org>; Tue, 3 Nov 2015 11:16:57 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 03 Nov 2015 02:16:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208";a="841390156" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.62]) by orsmga002.jf.intel.com with SMTP; 03 Nov 2015 02:16:54 -0800 Received: by (sSMTP sendmail emulation); Tue, 03 Nov 2015 10:16:53 +0025 Date: Tue, 3 Nov 2015 10:16:53 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Panu Matilainen <pmatilai@redhat.com> Message-ID: <20151103101653.GB15320@bricha3-MOBL3> References: <6594B51DBE477C48AAE23675314E6C460F1B8B6E@fmsmsx107.amr.corp.intel.com> <1445955906-8505-1-git-send-email-bruce.richardson@intel.com> <563863D5.8010708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <563863D5.8010708@redhat.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] compile and install using configure-make-make_install X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 03 Nov 2015 10:16:58 -0000 On Tue, Nov 03, 2015 at 09:35:49AM +0200, Panu Matilainen wrote: > On 10/27/2015 04:25 PM, Bruce Richardson wrote: > >Just clarify a bit further the idea I had in mind, I've put together the following > >two example patches. After applying these patches the following sequence of > >operations works to install dpdk libraries and headers into /opt (/opt/lib/dpdk > >and /opt/include/dpdk respectively). Also the machine type is changed from native > >to default, and the settings for KNI are disabled. > > > > ./configure --prefix=/opt --machine=default \ > > --config=RTE_LIBRTE_KNI=n \ > > --config=CONFIG_RTE_KNI_KMOD=n > > cd build > > make > > sudo make install > > I think I like the idea of a configure script that hides (some of) the DPDK > config peculiarities behind a more familiar looking interface. For example > it could be used for figuring out the machine-os-compiler triplet > automatically for the common cases. > > However having "make install" behave differently depending on which > directory its invoked from I dunno. Its unlike anything else out there (that > I know of) and I thought the idea was to make DPDK behave more like a normal > OSS citizen :) > > - Panu - > Yes, I would agree with your complaint. Unfortunately, I can't see any quick-fix way for it in the short term. Ideally, I think we should look to rename the existing "make install " option to something else, and then later look to add in a proper make install like above. For example: I would suggest in one release e.g. 2.2 to rename make install to e.g. "make sdk" or "make target" [I like make target, since it implies that you specify what the target should be with T="..."]. At that point, we add a new "make install" rule which simply prints out "make install is deprecated, use 'make target' instead." Then we wait a couple of releases to allow everyone to switch over to the new rule. Once done, then we can look to introduce a new, more standard, "make install" type target. [And in this case, I think limiting it to a build subdir or some such would also be helpful, just to help those doing a multi-version upgrade jump] /Bruce