ptest.bbclass will package ptest scripts in ${libdir}, which may include /usr/lib64 in some multilib configurations. However, ptest-runner is hard-coded to look at /usr/lib by default, requiring an extra -d /usr/lib64 to execute the default ptest-packaged test suites in these multilib configurations. This means any automated infrastructure that wants to invoke ptest-runner must be aware of the target architecture to instruct ptest-runner where to find test cases installed by the default arch-dependent ptest packages. Instead, it would be preferable for ptest-runner to find the default ptest-packaged test suites independent of the arch. I posted a naive fix to the mailing list to handle the default /usr/lib64 case, though I realize it doesn't allow support for actual multilib test suites (e.g. lib32-libfoo-ptest). https://lists.yoctoproject.org/pipermail/yocto/2018-February/039997.html Ross proposed fixing this in ptest-runner instead, but making ptest-runner's DEFAULT_DIRECTORY defined by ${libdir} still doesn't allow ptest-runner to automatically find multilib suites (e.g. lib32-libfoo-ptest) in a /usr/lib64 configuration. It seemed to me that there were more comprehensive approaches that could be taken to handle multilib setups (https://lists.yoctoproject.org/pipermail/yocto/2018-February/040011.html), so if we can converge on a solution here I'll be glad to workup and test out some new patches. (Or I can just move the naive approach to ptest-runner.)
(In reply to comment #0) > ptest.bbclass will package ptest scripts in ${libdir}, which may include > /usr/lib64 in some multilib configurations. However, ptest-runner is > hard-coded to look at /usr/lib by default, requiring an extra -d /usr/lib64 > to execute the default ptest-packaged test suites in these multilib > configurations. This means any automated infrastructure that wants to > invoke ptest-runner must be aware of the target architecture to instruct > ptest-runner where to find test cases installed by the default > arch-dependent ptest packages. Instead, it would be preferable for > ptest-runner to find the default ptest-packaged test suites independent of > the arch. > > I posted a naive fix to the mailing list to handle the default /usr/lib64 > case, though I realize it doesn't allow support for actual multilib test > suites (e.g. lib32-libfoo-ptest). > > https://lists.yoctoproject.org/pipermail/yocto/2018-February/039997.html > > Ross proposed fixing this in ptest-runner instead, but making ptest-runner's > DEFAULT_DIRECTORY defined by ${libdir} still doesn't allow ptest-runner to > automatically find multilib suites (e.g. lib32-libfoo-ptest) in a /usr/lib64 > configuration. > > It seemed to me that there were more comprehensive approaches that could be > taken to handle multilib setups > (https://lists.yoctoproject.org/pipermail/yocto/2018-February/040011.html), > so if we can converge on a solution here I'll be glad to workup and test out > some new patches. (Or I can just move the naive approach to ptest-runner.) My proposal is to add ptest-runner the ability to specify more than one directory in this case ptest.bbclass can setup multilib libdirs + default libdir.
Review at, https://lists.yoctoproject.org/g/yocto/message/49115
OE-Core recipe upgrade and oeqa case at, https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_ptest_runner/73336814
Merged at, http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=792d1ebba98b097d4d68c7261bf6af0c9d186eab http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=81b8656f6beae97fb1f4a99b1d92f71077c716e1