From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] reserve 'make install' for future use Date: Mon, 30 Nov 2015 12:27:14 +0100 Message-ID: <2760426.SYAZ0tSqOg@xps13> References: <1446805454-17776-1-git-send-email-bruce.richardson@intel.com> <3475702.r5OlE1Gpee@xps13> <59AF69C657FD0841A61C55336867B5B03598A952@IRSMSX103.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: "Richardson, Bruce" Return-path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id F215358DB for ; Mon, 30 Nov 2015 12:28:22 +0100 (CET) Received: by wmww144 with SMTP id w144so133222322wmw.0 for ; Mon, 30 Nov 2015 03:28:22 -0800 (PST) In-Reply-To: <59AF69C657FD0841A61C55336867B5B03598A952@IRSMSX103.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 = RTE_SDK/include/dpdk) > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > While doing it, we can have a specific handling of T= 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= 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= compatibility would be only a shortcut to do "make config" and name the build directory based on 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 different 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=" > * you can have standard(ish) configure/make/make install behavior using: > make config T= > 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.