From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 7936E8E90 for ; Fri, 4 Dec 2015 16:58:19 +0100 (CET) Received: by wmww144 with SMTP id w144so70496685wmw.0 for ; Fri, 04 Dec 2015 07:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=N3CVs8EHTzWeejIGdWQag+sQvi84JDcObOibnI923Tk=; b=fUlIQ0uIIRfcK98sB5+CpFL9vh+yDIrWKiSqRTAFnEOOTc/J8T1xY/2Xce7VmkF75V jakXwxKrD7cjWABFKRWfUpGKp9DCySbptucNUtm20To+brGKtAQg+CkhQPIXMGPGyzl/ bYiylT0qbiqi3g4dYMV35oiDA0PDqYf1dEpT6Rgt8CB9vyp+ZUmGx1pTMaUCVosZY6LB ZwqYLsHxKB2Jn9MQHB/55LQo+sSUTQfXAf7wGSuHnpJWYuyOC+R9Eg/RfgKFKnU22NXZ oNo+o4yufW6dcXoFu+jZJz7q1vBN76gDGRZcsee9TvvvTgpfWtSchwWf29PVpMYFFiBQ i5hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=N3CVs8EHTzWeejIGdWQag+sQvi84JDcObOibnI923Tk=; b=TjA+t8Dintz6e6tBGkxkX9EVND4T/mPhBswt27o2LT54LWF6jeD8a40sduICVfHCUv bQ9YO9Z6acjXVsVdB9DbxpMF9Ph+4C+Varfk94xc0BJYt2cnnoQY5eVkfwI5ey8/60uD xwL5q2DL4ij6JcjeYpDRQ3aBeXSYi1ra0XUCyj6VLYyCs+zk7H2cb180RedcBXB7OmIx SIztPUEuzjaWO8IimzBGNf+79NN7ul5GLn6k59Yj/tkoL4pE9fzzKjdPbc7PhPiX9ai7 mZAJdU6VK/E0ZBmFo+khxTHaU4hzLgHyGt+mNyOCAybU8kccmDO6VqiV4/3+Q2cSpqqm TWzQ== X-Gm-Message-State: ALoCoQmFanKsP44h9vnePOhOKR0GQavoWRDQw2fb5O8Jo9HH1immHskTNFBO+iTAgTh+3zzbYfDJ X-Received: by 10.28.179.68 with SMTP id c65mr5735053wmf.81.1449244699112; Fri, 04 Dec 2015 07:58:19 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id z66sm4104260wmz.7.2015.12.04.07.58.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Dec 2015 07:58:18 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Date: Fri, 04 Dec 2015 16:57:08 +0100 Message-ID: <1692572.r1sB5lKFV2@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <10499878.KsiGVSYioF@xps13> References: <1446805454-17776-1-git-send-email-bruce.richardson@intel.com> <20151130114927.GA27968@bricha3-MOBL3> <10499878.KsiGVSYioF@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 15:58:19 -0000 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 = 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. > > > > > > 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 the "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 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=" could be renamed in a later release when the new install will be well known.