tests: try to populate lt-ublk.{target} first in test code

[ming1]

The test code runs the executable from the top directory, which is actually one script, and finally 'lt-ublk' could be generated in .libs/, but 'lt-ublk.${target}' can't be generated in this way, and causes test failure, see issue github #102 when running ublk test on rhel10.

Fixes it by trying to populate 'lt-ublk.${target}' first by running 'ublk.{target} help' command.

[ming1]

Hello @RonnieSahlberg

Care to take a look and see if way is good?

Thanks,

[RonnieSahlberg]

Ouch. Yes, that is a good workaround for now.
Alternatively you can run "ublk.null add -t null -q 1 ..." instead of "ublk add -t null -q 1 ..."

I will work on a fix for upstream.

[sahlberg]

Autotools is pretty terrible sometimes :-(

For the tests I think perhaps just calling the target specific programs directly instead of via "ublk" might be a viable option when just running them from the test directory as I mentioned above.

[ming1]

Ouch. Yes, that is a good workaround for now. Alternatively you can run "ublk.null add -t null -q 1 ..." instead of "ublk add -t null -q 1 ..."

I'd suggest to avoid that:

• too many changes

• we need to support background for each target code of ublk.{target}

Thanks,

[sahlberg]

Another alternative could be to add a check if execve() fails due to not finding the executable
then we could try running "./" + argv[0] + ".target" instead.

• "./" if argc[0] does not contain any path components. Let me try some.

No, that wouldn't work. Well well this PR fixes it for the tests.

[ming1]

Another alternative could be to add a check if execve() fails due to not finding the executable then we could try running "./" + argv[0] + ".target" instead.

* "./" if argc[0] does not contain any path components.   Let me try some.

No, that wouldn't work. Well well this PR fixes it for the tests.

The issue can't happen on installed binary, which won't be libtool script or lt-ublk, so it should be fine to workaround it in test script.

Thanks,