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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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=<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.

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.