From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4CF89C1BC for ; Thu, 22 Oct 2015 16:57:15 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 22 Oct 2015 07:57:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,182,1444719600"; d="scan'208";a="800249731" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.66]) by orsmga001.jf.intel.com with SMTP; 22 Oct 2015 07:57:12 -0700 Received: by (sSMTP sendmail emulation); Thu, 22 Oct 2015 15:57:11 +0025 Date: Thu, 22 Oct 2015 15:57:11 +0100 From: Bruce Richardson To: Panu Matilainen Message-ID: <20151022145711.GA24256@bricha3-MOBL3> References: <6594B51DBE477C48AAE23675314E6C460F1B724F@fmsmsx107.amr.corp.intel.com> <20151020091728.GA17840@bricha3-MOBL3> <5627E436.2050106@6wind.com> <56287A5D.3030203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56287A5D.3030203@redhat.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] dpdk proposal installation process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:57:16 -0000 On Thu, Oct 22, 2015 at 08:55:41AM +0300, Panu Matilainen wrote: > On 10/21/2015 10:15 PM, Olivier MATZ wrote: > >Hi Mario, > > > >On 10/20/2015 11:17 AM, Bruce Richardson wrote: > >>On Tue, Oct 20, 2015 at 12:21:00AM +0000, Arevalo, Mario Alfredo C wrote: > >>>Hi folks, > >>> > >>> Good day, this is a proposal in order to improve the dpdk install process, > >>>I would like to know your point of view about the next points according to > >>>previous conversations :) in order to create a new patches version. > >>> > >>>1) I think the first thing that I have to be aware is "compatibility", the > >>>new changes won't affect the current dpdk behaviour. > > > >Yes. As I stated in a previous mail, I think nobody uses the current > >"make install" without specifying T= as the default value is to build > >and install for all targets. > > > >My suggestion is: > > > >- rename the previous "install" target. The name could probably > > be "mbuild" (for multiple builds). Other ideas are welcome. > > > >- when "make install" is invoked with T= argument, call the mbuild > > target to have the same behavior than before. This compat layer > > could be removed in the future. > > > >- when "make install" is invoked without T=, it installs the fhs. > > Nice, this sounds like the best of both worlds. > > > > >>>2) Create new makefile rules, these rules is going to install dpdk files in > >>>default paths, however the linux distributions don't use the same paths for their > >>>files, the linux distribution and the architecture can be factor for different > >>>path as Panu commented in previous conversations, he is right, then all variables > >>>could be overridden, the variables names for the user can be included in documentation. > >>>Also an option could be a configuration file for paths, however I'm not sure. > > > >I think having variables is ok. > > > >>>3) The default paths for dpdk in order to follow a hierarchy, however the variable > >>>with those values can be overridden. > >>> > >>>-install-bin --> /usr/bin. > >>>-install-headers --> /usr/include/dpdk > >>>-install-lib --> /usr/lib64 > > > >I remember Panu suggested to have /usr/lib by default. > >I also think /usr/lib a better default value: some distributions > >use /usr/lib for 64 bits libs, but we never have 32 bits libs in > >/usr/lib64. > > Yes, just stick /usr/lib there and be done with it, lib64 is not a good > default for these very reasons. > > >>>-install-doc --> /usr/share/doc/dpdk > >>>-install-mod --> if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk > >>> else KERNEL_DIR=/boot/modules). > > > >I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR? > > > >>>-install-sdk --> /usr/share/dpdk and call install-headers ). > >>>-install-fhs --> call install-libraries, install-mod, install-bin and install-doc (maybe install-headers) > >>> > >>>4) I'm going to take account all feedback about variables, paths etc for the new version :). > >>> > >>>Thank you so much for your help. > >>> > >>> > >>>Mario. > >> > >>Hi Mario, > >> > >>that seems like a lot of commands to add - are they all individually needed? > >> > >>In terms of where things go, should the "usr" part not a) be configurable via > >>a parameter, and b) default to "/usr/local" as that's where user-installed > >>software from outside the packaging system normally gets put. > > > >A PREFIX variable would do the job. > >About the default to /usr or /usr/local, I agree that /usr/local looks > >more usual, and I don't think it's a problem for packaging as soon as > >it can be overridden. > > Yeah, PREFIX support would be nice, and defaulting that to /usr/local would > be the right thing. > > - Panu - > > > > > > >Regards, > >Olivier > > > Can I throw a completely different suggestion into the mix? Can we make use of the fact that make config creates a directory called "build" by default. Then running "make" alone in that directory does the expected behaviour of a compile of the whole sdk. How about having "make install" in the build directory behave like a generic "make install" call for other packages? I'm imagining the following sequence of steps to install: ./configure --machine=[default|native|other] # configure is a simple script that just calls "make config T=..." cd build make make install Thoughts? /Bruce