From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4650358DB for ; Mon, 30 Nov 2015 12:42:30 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP; 30 Nov 2015 03:42:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,364,1444719600"; d="scan'208";a="4690510" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga004.fm.intel.com with ESMTP; 30 Nov 2015 03:42:17 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by irsmsx105.ger.corp.intel.com ([169.254.7.203]) with mapi id 14.03.0248.002; Mon, 30 Nov 2015 11:41:33 +0000 From: "Richardson, Bruce" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] reserve 'make install' for future use Thread-Index: AQHRGH1R5l7mNw/cT02gAmPgqZ6ZoJ6O9HcAgAACAwCAHIoYAIABCqqAgAO3OYCABEiSEIAACB0AgAACMkA= Date: Mon, 30 Nov 2015 11:41:32 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03598A978@IRSMSX103.ger.corp.intel.com> References: <1446805454-17776-1-git-send-email-bruce.richardson@intel.com> <3475702.r5OlE1Gpee@xps13> <59AF69C657FD0841A61C55336867B5B03598A952@IRSMSX103.ger.corp.intel.com> <2760426.SYAZ0tSqOg@xps13> In-Reply-To: <2760426.SYAZ0tSqOg@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.181] 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: Mon, 30 Nov 2015 11:42:30 -0000 > -----Original Message----- > 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 >=20 > 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 supp= ort > 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. >=20 > 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 d= o > "make config" and name the build directory based on the template name. >=20 > About the environment variables: > An application requires CFLAGS and LDFLAGS (at least). The standard way t= o > 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. >=20 > > 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, w= e > can then look to implement a proper "make install" command that works in = a > standard way, perhaps alongside a configure script of some description. >=20 > I think we don't need to rename or move some code. > Just drop and replace some of them. >=20 > The configure script is a great idea but it is a totally different idea. > I do not think that installation and configuration should be related. > Please let's consider "make install" first. >=20 > > 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. >=20 > 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_T= ARGET needs to be supported for some time for those projects already familiar wit= h it and using it. As well as this, we also need a sane way of building DPDK inside the "build= "=20 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 s= dk" are provided for backward compatibility. Inside the build directory you hav= e 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.=20 Yes, I would like the ideal state where we have one set of build commands t= hat are run from just one location. However, I don't think we can get to that o= bjective without going through a transition phase where we support both old and new = options. /Bruce