Re: [dpdk-dev] compile and install using configure-make-make_install

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

On Tue, Nov 03, 2015 at 09:35:49AM +0200, Panu Matilainen wrote:
> On 10/27/2015 04:25 PM, Bruce Richardson wrote:
> >Just clarify a bit further the idea I had in mind, I've put together the following
> >two example patches. After applying these patches the following sequence of
> >operations works to install dpdk libraries and headers into /opt (/opt/lib/dpdk
> >and /opt/include/dpdk respectively). Also the machine type is changed from native
> >to default, and the settings for KNI are disabled.
> >
> >	./configure --prefix=/opt --machine=default \
> >		--config=RTE_LIBRTE_KNI=n \
> >		--config=CONFIG_RTE_KNI_KMOD=n
> >	cd build
> >	make
> >	sudo make install
> 
> I think I like the idea of a configure script that hides (some of) the DPDK
> config peculiarities behind a more familiar looking interface. For example
> it could be used for figuring out the machine-os-compiler triplet
> automatically for the common cases.
> 
> However having "make install" behave differently depending on which
> directory its invoked from I dunno. Its unlike anything else out there (that
> I know of) and I thought the idea was to make DPDK behave more like a normal
> OSS citizen :)
> 
> 	- Panu -
> 

Yes, I would agree with your complaint.

Unfortunately, I can't see any quick-fix way for it in the short term. Ideally,
I think we should look to rename the existing "make install " option to something
else, and then later look to add in a proper make install like above.

For example: I would suggest in one release e.g. 2.2 to rename make install to
e.g. "make sdk" or "make target" [I like make target, since it implies that you
specify what the target should be with T="..."].
At that point, we add a new "make install" rule which simply prints out
"make install is deprecated, use 'make target' instead."

Then we wait a couple of releases to allow everyone to switch over to the new rule.
Once done, then we can look to introduce a new, more standard, "make install" type
target. [And in this case, I think limiting it to a build subdir or some such
would also be helpful, just to help those doing a multi-version upgrade jump]

/Bruce