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.