From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 6306E6A80 for ; Mon, 26 Oct 2015 17:18:05 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 26 Oct 2015 09:18:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,201,1444719600"; d="scan'208";a="803349947" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga001.jf.intel.com with ESMTP; 26 Oct 2015 09:18:02 -0700 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 26 Oct 2015 09:18:01 -0700 Received: from fmsmsx107.amr.corp.intel.com ([169.254.6.163]) by fmsmsx123.amr.corp.intel.com ([169.254.2.23]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 09:18:01 -0700 From: "Arevalo, Mario Alfredo C" To: "Richardson, Bruce" , Panu Matilainen Thread-Topic: [dpdk-dev] dpdk proposal installation process Thread-Index: AdEKzTKfKaaYZAaBQP+Bu9jCtTvTPwAhZ5CAAEcpHgAAFl/bgAAS6WOAAL1CswA= Date: Mon, 26 Oct 2015 16:18:00 +0000 Message-ID: <6594B51DBE477C48AAE23675314E6C460F1B8B6E@fmsmsx107.amr.corp.intel.com> References: <6594B51DBE477C48AAE23675314E6C460F1B724F@fmsmsx107.amr.corp.intel.com> <20151020091728.GA17840@bricha3-MOBL3> <5627E436.2050106@6wind.com> <56287A5D.3030203@redhat.com> <20151022145711.GA24256@bricha3-MOBL3> In-Reply-To: <20151022145711.GA24256@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 26 Oct 2015 16:18:06 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Thursday, October 22, 2015 9:57 AM > To: Panu Matilainen > Cc: Olivier MATZ; Arevalo, Mario Alfredo C; dev@dpdk.org > Subject: Re: [dpdk-dev] dpdk proposal installation process >=20 > 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 creat= e 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=3D as the default value is to buil= d > > >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=3D 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=3D, 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=3Dlinuxapp then > KERNEL_DIR=3D/lib/modules/$(uname -r)/extra/drivers/dpdk > > >>> else KERNEL_DIR=3D/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, insta= ll-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 syste= m > 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 > > > > > >=20 > Can I throw a completely different suggestion into the mix? >=20 > 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? >=20 > I'm imagining the following sequence of steps to install: >=20 > ./configure --machine=3D[default|native|other] > # configure is a simple script that just calls "make config T=3D..." > cd build > make > make install >=20 > Thoughts? >=20 > /Bruce Hi Guys, Thank you so much for your feedback, about your last comments, I understood the next: 1) -"make install" using "T" variable: This command will use a rule for the current behaviour called "mbuild" -"make install" without "T" variable: This command will install everything: headers, libraries, modules, apps, do= cs, and sdk files (config files, make files, scripts and examples). 2) About variables, you rigth, KMOD_DIR sounds better than KERNEL_DIR, and LIB_DIR should be /usr/lib by default. 3) -To use a "prefix variable" -This prefix variable will be "/usr/local" by default. -This prefix variable can be overridden. Example: $(DESTDIR)/$(PREFIX)/$(INCLUDE_DIR) 4) What do you think about the Bruce's proposal?