From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=MWr428Rr8WjlJp/nXCINZYCNDte5WfsZ4qPV+vcs/5c=; b=olD6BEbYTVQRrU5/6//UWuf5X4raC8e+vtclt+idoz6OYQlzVpLEVb4B1eREGtPdDx ejJ6uaxhf/dLzXnamrlYKJzs6FTx5nYFPLylbIbuD+Jwm16svrpQIzaOrQGjOyLnWVr0 hsrStmaVuyDE3wVTrhioce+310znuDWUp8hGXxXQem5eT53k12ndgBJ0/LmJf2arD8b0 6UO1MVhKUq+9qleUtmWrJ+Cn9gPANVlpyFrPFvwwm2qudbZycnM2HKbIKoS5pGMdrtxC yadjr8UttNZDfiD87oSP2+w4HmLhROvVAmzN0m4nEBpACdtgR2L8criM44xj0qLZhtHn XC1Q== 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=MWr428Rr8WjlJp/nXCINZYCNDte5WfsZ4qPV+vcs/5c=; b=OiLv0A4gD7eE1C9zBPewkD+2fOB+6ejgslZIGSqcqZfs/rvv4OJt8vRRZ7eo7Nf2aE 6xTuVwpJM+VP6i1g16I5nJPXSL8sYBRd5LI+obcHqvkchiZoXeb/1Nhk2YnIVyJBQMRO iZ8QDGGvaxXuMuQ9aOn7qFNrPsCZ3FZ/0Aqlt49kjtXf/M584k2GnafFXdEuEHiH9vrg ruehhOf9d04WRIMKtRKAfqNN+2lgp1fdBwpzOnIDiUbImuwciotpq/wKeiYTNfniv+JH kn3hSqoJv5AsnHG6ap3ONYkvWLS7Yzi4Ns/3SXGxwqitFggOLCUJ5jdRxuUPDT0/chCj zJhA== X-Gm-Message-State: ALoCoQlQl0MHo3YPS5YReOq8mLTWVdDZ3l3TEjk2Qb5oi+FQ+WOQPR8+eb+0UnPhDEnJe9Q/EZi2 X-Received: by 10.194.178.70 with SMTP id cw6mr72298199wjc.73.1448882902551; Mon, 30 Nov 2015 03:28:22 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id vr10sm46505596wjc.38.2015.11.30.03.28.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 03:28:21 -0800 (PST) From: Thomas Monjalon To: "Richardson, Bruce" Date: Mon, 30 Nov 2015 12:27:14 +0100 Message-ID: <2760426.SYAZ0tSqOg@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <59AF69C657FD0841A61C55336867B5B03598A952@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> 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: Mon, 30 Nov 2015 11:28:23 -0000 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.