Summary: | Mk/bsd.port.mk: tests are not parallelized; DO_MAKE_TEST does not contain ${_MAKE_JOBS} | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Matthias Andree <mandree> |
Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
Status: | Open --- | ||
Severity: | Affects Some People | CC: | diizzy, portmgr, ports-bugs |
Priority: | --- | Keywords: | needs-patch, performance |
Version: | Latest | Flags: | koobs:
maintainer-feedback?
(portmgr) |
Hardware: | Any | ||
OS: | Any |
Description
Matthias Andree
2021-10-31 14:35:57 UTC
I'm not saying its a bad idea but looking at other repos in general unit tests seems to be a bit sensitive to parallel jobs so this might more work than its worth and since they aren't built/run by default I don't think we need to worry too much about time spent running tests. Daniel, I have yet to see a port which is either my port, or an important requisite to one of my ports, where a "make test" fails when run in parallel. In an era of 8-or-more threads ubiquitous, this isn't an excuse. In the long run, we should probably also run a decent test set by default on the builders, and leave only long-runners optional. We can of course offer a framework parameter such as TEST_JOBS_NUMBER (which would default to MAKE_JOBS_NUMBER) so it's overridable to 1 or a Boolean-logic TEST_JOBS_UNSAFE switch, and when globally running out tests in some future point in time, this will warrant -exp runs, but none of that is a hindrance to fixing test performance now. (In reply to Matthias Andree from comment #2) s/running out/rolling out/ I am all for a patch which would provide en equivalent of _MAKE_JOBS for DO_MAKE_TEST, when providing the patch, please also provide a TEST_MAKE_JOB_UNSAFE knob or equivalent. |