This is a common annoyance that I have to look up every time. First, the only readable description of BDEPEND is in Michał's article: https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#build-time-dependencies-split-into-depend-and-bdepend But even from that, it's not clear where test dependencies should go. Are they run during the build (on the build host), or during install (on the target host)? The devmanual, https://devmanual.gentoo.org/ebuild-writing/functions/src_test/ says that the purpose of src_test is to "run pre-install test scripts," suggesting that test dependencies need to be installed on the target host. However the PMS, https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-930009.1.8 says that "the src_test function runs unit tests for the newly built but not yet installed package as provided." To me that sounds like the test dependencies need to be in BDEPEND. Digging into the PMS description for BDEPEND seems to confirm this: BDEPEND build dependencies that are binary compatible with the native build system (CBUILD). The ebuild is allowed to call binary executables installed by this kind of dependency. DEPEND build dependencies that are binary compatible with the system being built (CHOST). The ebuild must not execute binary executables installed by this kind of dependency. Does src_test count as "executing binary executables?" Presumably... so, I have arrived at the conclusion that test dependencies should look something like BDEPEND="... test? ( ${RDEPEND} ${DEPEND} test-dep1 test-dep2 ... )" I'm only guessing that DEPEND needs to be in there too, since any libraries needed to run the program are likely to be necessary for the test suite as well. In any case, if this (or a correct version of it, if I'm completely wrong) were all in the devmanual, it would save me a lot of time.
(In reply to Michael Orlitzky from comment #0) > But even from that, it's not clear where test dependencies should go. Are > they run during the build (on the build host), or during install (on the > target host)? Test dependencies are not different from other build-time dependencies. If src_test() executes some executables from package X, then X should be in BDEPEND: BDEPEND="... test? ( X )" If src_test() builds its own executables (or src_compile() does it conditionally on "test" USE flag) and these executables require headers/libraries from package Y, then Y should be in DEPEND: DEPEND="... test? ( Y )" Real examples of tests-related packages which should be in DEPEND: dev-cpp/gtest dev-libs/check dev-qt/qttest (There may be some situations when tests-related package should be in both BDEPEND and DEPEND.)
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > > If src_test() builds its own executables (or src_compile() does it > conditionally on "test" USE flag) and these executables require > headers/libraries from package Y, then Y should be in DEPEND: > > DEPEND="... test? ( Y )" > I think it would be highly beneficial to enumerate the common cases. For example: I'm building a binary, command-line tool. Its test suite consists of running the tool on some example input, and checking the output. What should {,R,B}DEPEND look like? In that situation, the "test executable" is the regular executable. If it's linked to zlib, shouldn't zlib be in BDEPEND too, since the tool that's linked to zlib will be run on the build host? Or does putting it only in DEPEND suffice?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > If src_test() builds its own executables (or src_compile() does it > conditionally on "test" USE flag) Intention of test suite is to early check if given package is expected to work after installation to target system (CHOST). During crosscompilation, these executables usually cannot be run on host system (CBUILD). If full correctness in ebuilds was intended, then something like this would be needed: RESTRICT="crosscompilation? ( test ) !test? ( test )"
