From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 0A3E28E92 for ; Fri, 4 Dec 2015 17:21:10 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2015 08:21:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,380,1444719600"; d="scan'208";a="853999273" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 04 Dec 2015 08:21:09 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 4 Dec 2015 16:21:08 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by IRSMSX156.ger.corp.intel.com ([169.254.3.110]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 16:21:08 +0000 From: "Richardson, Bruce" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] reserve 'make install' for future use Thread-Index: AQHRGH1R5l7mNw/cT02gAmPgqZ6ZoJ6O9HcAgAACAwCAHIoYAIABCqqAgAO3OYCABEiSEIAACB0AgAACMkCAAAQDgIAAK96AgAZiqQCAAAaXUA== Date: Fri, 4 Dec 2015 16:21:07 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03598D905@IRSMSX103.ger.corp.intel.com> References: <1446805454-17776-1-git-send-email-bruce.richardson@intel.com> <20151130114927.GA27968@bricha3-MOBL3> <10499878.KsiGVSYioF@xps13> <1692572.r1sB5lKFV2@xps13> In-Reply-To: <1692572.r1sB5lKFV2@xps13> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 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: Fri, 04 Dec 2015 16:21:11 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, December 4, 2015 3:57 PM > To: Richardson, Bruce > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use >=20 > 2015-11-30 15:26, Thomas Monjalon: > > 2015-11-30 11:49, Bruce Richardson: > > > On Mon, Nov 30, 2015 at 11:41:32AM +0000, Richardson, Bruce wrote: > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > Sent: Monday, November 30, 2015 11:27 AM > > > > > To: Richardson, Bruce > > > > > Cc: Panu Matilainen ; dev@dpdk.org; > > > > > olivier.matz@6wind.com > > > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for > > > > > future use > > > > > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > > > Why is it a step in the right direction? > > > > > > > > > > > > > > We just need to install the files in a different hierarchy > > > > > > > and adapt the makefiles to be able to compile an application > > > > > > > while keeping the RTE_SDK variable to specify the root > > > > > > > directory (previously built thanks to DESTDIR). > > > > > > > As the hierarchy could be tuned, we need more variables, e.g.= : > > > > > > > DPDK_INC_DIR (default =3D RTE_SDK/include/dpdk) > > > > > > > DPDK_LIB_DIR (default =3D RTE_SDK/lib) > > > > > > > > > > > > > > While doing it, we can have a specific handling of T=3D to > > > > > > > keep compatibility with the current (old) syntax. > > > > > > > > > > > > > > What have I missed? > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use > > > > > > for this, > > > > > without having it heavily overloaded. The existing T=3D behavior > > > > > has support for wildcards and compiling multiple instances at > > > > > the same time - something that won't work with a scheme to > > > > > actually install DPDK throughout the filesystem hierarchy. > > > > > Having it sometimes behave as now, and sometimes behave as a > > > > > standard make install is a bad idea IMHO, as it confuses things. > > > > > Having lots of extra environment variables is also not a great > idea, to my mind. > > > > > > > > > > Yes I agree. > > > > > I forgot to mention it, but in my idea, we can drop the support > > > > > for multiple targets. So the T=3D compatibility would be only a > > > > > shortcut to do "make config" and name the build directory based o= n > the template name. > > > > > > > > > > About the environment variables: > > > > > An application requires CFLAGS and LDFLAGS (at least). The > > > > > standard way to provide them is pkgconfig (not implemented yet). > > > > > For applications using the DPDK makefiles, the only input is > RTE_SDK. > > > > > When allowing more tuning in paths, we need more variables when > > > > > using the DPDK makefiles to build an application. > > > > > > > > > > > My opinion is that we should rename our existing "make > > > > > > install" to > > > > > something more suitable - my patch suggestion was "make sdk" but > > > > > it could be "make target" or something else if people prefer. > > > > > Once that is done, we can then look to implement a proper "make > > > > > install" command that works in a standard way, perhaps alongside = a > configure script of some description. > > > > > > > > > > I think we don't need to rename or move some code. > > > > > Just drop and replace some of them. > > > > > > > > > > The configure script is a great idea but it is a totally differen= t > idea. > > > > > I do not think that installation and configuration should be > related. > > > > > Please let's consider "make install" first. > > > > > > > > > > > For an easy enough solution, I would look to apply this patch > > > > > > to create > > > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to > > > > > have a "make install" command that works in the build dir. That > way: > > > > > > * you can have existing behavior using "make sdk T=3D" > > > > > > * you can have standard(ish) configure/make/make install > behavior using: > > > > > > make config T=3D > > > > > > cd build > > > > > > make > > > > > > make install > > > > > > and the "make config" step can subsequently be wrapped in a > > > > > > configure > > > > > script to eliminate the need to know what the best target to use > is, etc. > > > > > > > > > > As Panu commented, I do not think it is a good idea to have > > > > > different behaviours inside and outside of the build directory. > > > > > I would even say that this embedded makefile is only confusing > > > > > and should be dropped. > > > > > We need to have *one* right building methods, not to bring more > confusion. > > > > > > > > I disagree. I don't think we can have *one* right building method, > > > > because to do so means completely throwing away our existing > > > > methods of building DPDK and using sample applications. That > > > > general method, using RTE_SDK and RTE_TARGET needs to be supported > > > > for some time for those projects already familiar with it and using > it. > > > > We can keep it for some time while allowing other tree hierarchies. > > > > > > As well as this, we also need a sane way of building DPDK inside th= e > "build" > > > > directory, and having a "make install" target that installs the > > > > libraries and headers inside /usr/local (or whatever was specified > as $prefix). > > > > > > > > With regards to different behavior, since different targets are > > > > provided, I don't see it as a problem. In the root directory, "make > config" and "make sdk" > > > > are provided for backward compatibility. Inside the build > > > > directory you have your standard "make" and "make install" > > > > commands. Since the command set is very limited, it's easy enough > > > > to print a suitable error when the wrong command is used in the > wrong place. > > > > > > By way of follow-up to my own email, I'd also state that I would > > > indeed prefer not to have different targets in different places, and > > > that ideally you would do configure/make/make-install from the root > > > directory. The reason I suggested having "make install" work inside > > > the build directory is because of our existing use of "make install" > for something different in the root directory. > > > This is also the reason I sent out this patch. By renaming the "make > install" > > > command in 2.2, we give ourselves the option in future releases of > > > adding in a new "make install" command that behaves as we want, > > > without having to worry about conflict with a legacy make install. > > > > > > That is why I feel this one patch should go in - it opens up more > > > options for us in future releases. It's not an end in itself. :-) > > > > If we do not agree on something else (I'll try to submit some > > patches), yes your patch to introduce "make sdk" will be integrated. > > But I'd prefer avoiding to document a new command which will be > > deprecated when the new-new "make install" will be implemented. > > I think there is another solution (I may be wrong). > > > > > > Yes, I would like the ideal state where we have one set of build > > > > commands that are run from just one location. However, I don't > > > > think we can get to that objective without going through a > transition phase where we support both old and new options. > > > > > > > > /Bruce >=20 > The patch series for standard make install > (http://dpdk.org/ml/archives/dev/2015-December/029416.html) > demonstrates that it is possible to have a standard make install while > keeping the old behaviour. > So this patch is marked as rejected in patchwork. > To avoid confusion, the name of the old "make install T=3D" could be rena= med > in a later release when the new install will be well known. Ok, understood. /Bruce