Aaron Conole <acon...@redhat.com> writes: > Bruce Richardson <bruce.richard...@intel.com> writes: > >> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote: >>> From: Michael Santana <msant...@redhat.com> >>> >>> Currently many unit tests fail when running tests under shared builds. >>> This happens because of missing driver dependencies. This is fixed by >>> explicitly linking in missing drivers for the test application. >>> >>> before and after (clang): >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623 >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620 >>> >>> Suggested-by: Bruce Richardson <bruce.richard...@intel.com> >>> Suggested-by: David Marchand <david.march...@redhat.com> >>> Signed-off-by: Michael Santana <msant...@redhat.com> >>> Signed-off-by: Aaron Conole <acon...@redhat.com> >>> --- >> Rather than linking in the libraries explicitly, can you have the build do >> a "ninja install" at the end to place the libraries and drivers in their >> correct paths. That should mean that the test app (via eal) auto-loads all >> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make >> further changes to this file to link in any additional drivers.
Oops, forgot to include a link to a build where I did this. It's failing (you can see the corresponding commit at https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d): https://travis-ci.org/orgcandman/dpdk/jobs/566044409 >> EAL_PMD_PATH is based off of $prefix for the build or install, so you can >> adjust that using meson options, if putting the drivers in /usr/local is >> not desirable for your test environments. > > The downside of not explicitly linking this way is that a developer > won't be able to do something like: > > meson build > ninja -C build > > ... development work > > ninja -C build test > > Rather, they will notice broken tests and not care about testing any > more (since that's what we're dealing with now). > > Requiring that a developer do the install (ninja -C build install) then > presents a different problem: before doing the 'test' I *must* remember > to do the install. Otherwise I won't be testing with the correct > version of the libraries. > > Is there a way to adjust the library search path? Maybe we can solve > this by making that search path adjusted during the unit tests to look > in all the various build directories? > >> /Bruce
