RFE: stop "port test" immediately if no test phase defined

[dstrubbe (David Strubbe)]

If you run "port test" on a port, it will go through all the phases of checking dependencies, fetch, extract, configure, and build before finally giving an error like:

Error: org.macports.test for port scalapack returned: scalapack has no tests turned on. see 'test.run' in portfile(7)

It would be convenient if this check could be performed immediately, before carrying out any of the other steps (which might be quite time-consuming).

[cooljeanius (Eric Gallager)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

I agree. It is trivial to check for 'target equal test' in macports1.0/macports.tcl before or after installing dependencies. However, I'm at a lost of how to get the "test.run" option from the portfile. If someone can point me in the correct direction, I'll give this a shot.

[larryv (Lawrence Velázquez)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

Here's another try - I'm not sure if the 'info level' is the way to go here - looking for feedback.

[neverpanic (Clemens Lang)]

Replying to khindenburg@…:

I agree. It is trivial to check for 'target equal test' in macports1.0/macports.tcl before or after installing dependencies. However, I'm at a lost of how to get the "test.run" option from the portfile. If someone can point me in the correct direction, I'll give this a shot.

I agree with jmr that the test should be in macports1.0/macports.tcl. To get the value of test.run from the Portfile context, you can use $workername eval [list option test.run]. In theory, you could also use the _mportkey helper to get variables from the Portfile context, but that's currently broken with non-trivial variable names:

% set key test.run
test.run
% $workername eval [list set $key]
yes
% _mportkey $mport $key
can't read "test": no such variable
%

[neverpanic (Clemens Lang)]

I've fixed the problem with _mportkey in r140015. You can also use _mportkey $mport test.run now.

[kurthindenburg (Kurt Hindenburg)]

Thanks Cal - any comments about this implementation?

[jmroot (Joshua Root)]

You shouldn't throw an error in mportexec, it's meant to return 1 on failure. After the log has been pushed, you need to clean up by popping it before you return. (So maybe do this check before pushing the log.) The comment talks about dependents, which doesn't make much sense.

Maybe also consider whether this case should be considered a failure at all. Does it make more sense to say "We successfully ran all 0 tests that this port has" rather than "We failed to run any tests"?

[kurthindenburg (Kurt Hindenburg)]

Thanks

Since the user specifically asks for 'port test' I think it should fail if no tests are enabled.

I don't really like the the line to report a bug.

sudo port -v test py27-queuelib       
Error: py27-queuelib has no tests enabled; select another target.
Error: Follow http://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port py27-queuelib failed

[kurthindenburg (Kurt Hindenburg)]

I forgot all about this issue - ​https://github.com/macports/macports-base/pull/185

[jmroot (Joshua Root)]

In ddc26554e6ed49ce8501069b967284739fa6d34e/macports-base (master):

Add built-in test phase for all ports

For now, there's just one test, which checks that the files in the
destroot have the archs that the port is supposed to be building for.
More can be added in future.

Running 'port test' on a port that doesn't set 'test.run yes' will no
longer error, but will run the built-in tests only. Ports that do set
test.run will run both the built-in tests and the ones defined by the
Portfile.

Closes: #45010