Re: [dpdk-dev] [PATCH] devtools/test-meson-builds: allow custom set of examples

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

On Mon, Nov 09, 2020 at 08:26:10PM +0100, Thomas Monjalon wrote:
> 09/11/2020 19:02, Bruce Richardson:
> > On Mon, Nov 09, 2020 at 06:09:51PM +0100, Thomas Monjalon wrote:
> > > 27/10/2020 18:38, Bruce Richardson:
> > > > To test the installation process of DPDK using "ninja install"
> > > > test-meson-builds.sh builds a subset of the examples using "make".
> > > > To allow more flexibility for people testing, allow the set of
> > > > examples chosen for this make test to be overridden using variable
> > > > "DPDK_BUILD_TEST_EXAMPLES" in the environment.
> > > > 
> > > > Since a number of example apps link against drivers directly even
> > > > for shared builds, we need to ensure that LD_LIBRARY_PATH points to
> > > > the main DPDK lib folder so any dependencies of those drivers can
> > > > be found e.g. that the PCI/vdev bus driver .so is found. [All
> > > > drivers are symlinked from drivers dir back to lib dir on install,
> > > > so only one dir rather than two is needed in the path.]
> > > [...]
> > > > +libdir=$(dirname $(find $DESTDIR -name librte_eal.so)) +export
> > > > LD_LIBRARY_PATH=$libdir:$LD_LIBRARY_PATH
> > > 
> > > I don't get why libdir is required for some examples, and not for
> > > others? The pkg-config file is not enough?
> > > 
> > 
> > It's only needed for examples that link against drivers directly. 
> > 
> > I believe it's needed in those cases, because app linker flags
> > (including e.g. -lrte_pmd_bond) occur before the pkg-config flags,
> > which means that the linker at that point does not have the path to
> > find the dependencies of the driver. [In a normal build, this wouldn't
> > be necessary because the library directory would be a standard path]
> 
> If it's just a matter of ordering, it would be a better example to fix
> the ordering in the Makefile, isn't it?
> 

I thought about that, but it seems strange to have the DPDK linker flags
appear before the application specific flags. The general style is to have
the apps own linker flags apply first, and then the list of dependencies,
so that any app linker flags take precedence. The other option is to have
two separate LDFLAG variables for the app, one for before pkg-config flags
and the other afterwards, but that is an untidy solution.

Therefore, I think it's better to keep the ordering in the examples as-is
and just set the library path in the script. It's only a single extra
assignment that is necessary because we are installing to a non-standard
path using DESTDIR.

/Bruce