Re: [dpdk-dev] [PATCH] reserve 'make install' for future use

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, November 27, 2015 5:33 PM
> To: Panu Matilainen <pmatilai@redhat.com>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com
> Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use
> 
> 2015-11-25 10:48, Panu Matilainen:
> > On 11/24/2015 06:54 PM, Bruce Richardson wrote:
> > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote:
> > >> 2015-11-06 12:57, Bruce Richardson:
> > >>> So, any thoughts or comments on this? There has been lots of
> > >>> discussion in this general area but nothing yet going into the
> release to try and improve the situation.
> > >>>
> > >>> Are we just going to kick the problem down the road to the 2.3
> release?
> > >>
> > >> I plan to check these patches in the coming days for an integration
> in 2.2.
> > >>
> > > Anything further on this?
> > > Any thoughts from anyone else about this whole area of a saner
> > > build/install system for DPDK and the various patches floating around.
> >
> > Well, it seems we wont have a sane "make install" in 2.2 yet, but this
> > is at least a step in the right direction so +1 from me.
> 
> 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.

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. 

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=<target>"
* you can have standard(ish) configure/make/make install behavior using:
	make config T=<target>
	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.



/Bruce