[dpdk-dev] [PATCH] reserve 'make install' for future use
Thomas Monjalon
thomas.monjalon at 6wind.com
Mon Nov 30 12:27:14 CET 2015
2015-11-30 11:08, Richardson, Bruce:
> From: Thomas Monjalon [mailto:thomas.monjalon at 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.
More information about the dev
mailing list