From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <olivier.matz@6wind.com> Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id C43A2C482 for <dev@dpdk.org>; Wed, 21 Oct 2015 21:15:10 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from <olivier.matz@6wind.com>) id 1ZoyrI-0007Mn-4i; Wed, 21 Oct 2015 21:15:37 +0200 Message-ID: <5627E436.2050106@6wind.com> Date: Wed, 21 Oct 2015 21:15:02 +0200 From: Olivier MATZ <olivier.matz@6wind.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "Arevalo, Mario Alfredo C" <mario.alfredo.c.arevalo@intel.com> References: <6594B51DBE477C48AAE23675314E6C460F1B724F@fmsmsx107.amr.corp.intel.com> <20151020091728.GA17840@bricha3-MOBL3> In-Reply-To: <20151020091728.GA17840@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" <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 <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: Wed, 21 Oct 2015 19:15:10 -0000 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. >> 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. >> -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. Regards, Olivier