Issue that was discovered with bug 499580. PMS does not provide reference default_src_test implementation, stating just: "The default implementation used when the ebuild lacks the src_test function must, if tests are enabled, run emake check if and only if such a target is available, or if not run emake test if and only if such a target is available. In both cases, if emake returns non-zero the build must be aborted." It doesn't say specifically how to check "if such target is available". Existing eapi0 implementation in Portage for that likely comes from bug 350404. It invokes: make -n <target_to_check> Bug 499580 discovered that sometimes running make in 'dry run' mode is not enough. And indeed 'make' manual page says: " -n, --just-print, --dry-run, --recon Print the commands that would be executed, but do not execute them (except in certain circumstances). " Please note the "except in certain circumstances". As adding -i seems to make -n work really in 'dry run', I propose to fix default src_test in portage accordingly. @ulm Is it worth worth adding reference default src_test in PMS?
(In reply to Maciej Mrozowski from comment #0) > @ulm > Is it worth worth adding reference default src_test in PMS? CCing PMS team. Any opinion?
(In reply to Maciej Mrozowski from comment #0) > PMS does not provide reference default_src_test implementation, stating just: > "The default implementation used when the ebuild lacks the src_test function > must, if tests are enabled, run emake check if and only if such a target is > available, or if not run emake test if and only if such a target is > available. In both cases, if emake returns non-zero the build must be > aborted." That seems pretty clear. Check if the target is available, but otherwise don't care what it does. Passing -i looks like the right thing to do. > @ulm > Is it worth worth adding reference default src_test in PMS? Turning the argument around, if we had reference code there then most likely it would say "make -n" which maybe isn't correct. So having it only as a textual description is just fine.
(In reply to Ulrich Müller from comment #2) > That seems pretty clear. Check if the target is available, but otherwise > don't care what it does. Passing -i looks like the right thing to do. I'm going to test changing Portage to -i, given bug 955595.
(In reply to Sam James from comment #3) > (In reply to Ulrich Müller from comment #2) > > That seems pretty clear. Check if the target is available, but otherwise > > don't care what it does. Passing -i looks like the right thing to do. > > I'm going to test changing Portage to -i, given bug 955595. Or, rather, -i -n.
I object to using -i, it "ignores errors" but if you're actually running commands then the results of those commands seem unspecified and could leave your build tree in an inconsistent state. The bash-completion project has to solve the same issue: detect if targets exist, so they can be offered as tab completions. They run this command: make -npq .DEFAULT As no ".DEFAULT" target ever exists, no commands can ever run (but -n and -q provide extra assurance). Due to -p, a dump of rules / targets is emitted. This is then parsed by /usr/share/bash-completion/helpers/make-extract-targets.awk to get a list of targets. We could do something similar, to check for targets named "check" and "test".
