I had been careful to document and follow the same steps in ensuring I
was not imagining things. The problem of testing hanging right at the
end was persistent even after cleaning/resetting repository and
switching between CMake build methods (i.e. "Unix Makefiles" or Ninja).
For some reason, CMake plus Ninja was resulting in my testing observation.
I played with the testing parallelism value (`ctest -jx`) and 'poof' -
problem was gone. Testing finished almost instantaneously. Test #21
would finish in almost a quarter of a second. Weird.
After repeated clean/reset/build/test iterations, including switching
between gcc and clang compilers, this problem no longer presents itself.
I'm going to file this one under 'build gremlins'.
Roger,
Very much appreciate the assistance.
SF
On 2022-10-16 10:55, Roger Leigh wrote:
Hi Scott,
This isn't ninja at fault. Ninja itself should have a complete dependency
graph, so its behaviour should not be materially different than traditional
make--but it's usually much faster due to the lack of pattern rules etc since
they have to be expanded up front at generation time (by CMake).
I would firstly suggest splitting up the build and test steps. That might be one cause
of problems--the test rules might not depend upon the build products. That's likely due
to the "ctest" test framework being a bit separated from the build--it might
not know which targets to depend upon, so it expects you to build everything needed first.
Secondly, try running "ctest" rather than using the "test" target. This way you'll
invoke the test runner directly. This will let you control the parallelisation of the test execution. Use
"ctest -j nnn" to run with 1 or multiple parallel tests. If Xalan-C has issues with the tests
interfering with each other then this will identify if that's a problem, separate from any issues with the
build system.
Kind regards,
Roger
-----Original Message-----
From: Scott Furry <scott.wl.fu...@gmail.com>
Sent: 16 October 2022 17:09
To: c-users@xalan.apache.org
Subject: Re: Testing hangs with Ninja build method
Roger,
From what I have encountered in the past, Ninja appears notorious for
rushing to compile leaving "holes", gaps or otherwise in its wake on occasion.
It's easy to blame Ninja but it is also possible there is misconfiguration
involved. I'm not personally a fan of Ninja but I haven't made a point of
avoiding it outright. I thought it abnormal for Ninja and Makefiles to produce
different results when testing.
After a Ninja build, I had used `ctest -V ...`. It was giving me what I thought
was a verbose output. What was shown appeared unhelpful.
Output given:
-----
$ ninja -C build test
... (snip) ...
21: Started thread number 46, using pre-parsed documents.
21: Started thread number 47, using unparsed documents.
21: Started thread number 48, using pre-parsed documents.
21: Started thread number 49, using unparsed documents.
16/21 Test #14: TraceListen-3 .................... Passed 0.15 sec
17/21 Test #17: UseStylesheetParam ............... Passed 0.12 sec
18/21 Test #18: XalanTransform ................... Passed 0.11 sec
19/21 Test #19: XalanTransformerCallback ......... Passed 0.11 sec
20/21 Test #20: SimpleXPathCAPI .................. Passed 0.09 sec
21: Started thread number 50, using pre-parsed documents.
21: Started thread number 51, using unparsed documents.
21: Started thread number 52, using pre-parsed documents.
21: Started thread number 53, using unparsed documents.
21: Started thread number 54, using pre-parsed documents.
21: Started thread number 55, using unparsed documents.
21: Started thread number 56, using pre-parsed documents.
21: Started thread number 57, using unparsed documents.
21: Started thread number 58, using pre-parsed documents.
21: Started thread number 59, using unparsed documents.
21: Waiting for active threads to finish... # <-- indefinite hang
^C # <-- manually aborting process
