> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, November 27, 2015 5:33 PM > To: Panu Matilainen <pmatilai at redhat.com>; Richardson, Bruce > <bruce.richardson at intel.com> > Cc: dev at dpdk.org; olivier.matz at 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
