[dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

Aaron Conole aconole at redhat.com
Wed Jul 31 18:10:55 CEST 2019


Aaron Conole <aconole at redhat.com> writes:

> Bruce Richardson <bruce.richardson at intel.com> writes:
>
>> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
>>> From: Michael Santana <msantana at 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.richardson at intel.com>
>>> Suggested-by: David Marchand <david.marchand at redhat.com>
>>> Signed-off-by: Michael Santana <msantana at redhat.com>
>>> Signed-off-by: Aaron Conole <aconole at 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


More information about the dev mailing list