From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 05ABE8D8A for ; Thu, 22 Oct 2015 07:55:45 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id E4B944D; Thu, 22 Oct 2015 05:55:43 +0000 (UTC) Received: from dhcp195.koti.laiskiainen.org (vpn1-6-107.ams2.redhat.com [10.36.6.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9M5tgRX010222; Thu, 22 Oct 2015 01:55:42 -0400 To: Olivier MATZ , "Arevalo, Mario Alfredo C" References: <6594B51DBE477C48AAE23675314E6C460F1B724F@fmsmsx107.amr.corp.intel.com> <20151020091728.GA17840@bricha3-MOBL3> <5627E436.2050106@6wind.com> From: Panu Matilainen Message-ID: <56287A5D.3030203@redhat.com> Date: Thu, 22 Oct 2015 08:55:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5627E436.2050106@6wind.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 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 05:55:45 -0000 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 >