On 19. 7. 2026 16:53, Timofei Zhakov wrote:
On Sun, Jul 19, 2026 at 4:03 PM Branko Čibej <[email protected]> wrote:
On 19. 7. 2026 15:31, Daniel Sahlberg wrote:
Den sön 19 juli 2026 kl 01:18 skrev Timofei Zhakov
<[email protected]>:
On Sun, Jul 19, 2026 at 1:07 AM Daniel Sahlberg
<[email protected]> wrote:
Hi,
I'm sure I'm doing something wrong but I can't figure out
what.
svn_trunk2 is a regular checkout of trunk.
$ cmake -B out svn_trunk2 -DSVN_ENABLE_TESTS=ON
$ cd out
$ cmake --build
$ ctest
[...]
All Python-based tests (63 and up) fail with the same
error message:
[[[
Traceback (most recent call last):
File "/home/dsg/ramdisk/svn_trunk2/build/run_tests.py",
line 1127, in <module>
main()
~~~~^^
File "/home/dsg/ramdisk/svn_trunk2/build/run_tests.py",
line 1120, in main
failed = th.run(programs)
File "/home/dsg/ramdisk/svn_trunk2/build/run_tests.py",
line 597, in run
self._init_py_tests(list(py_basedir)[0])
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
File "/home/dsg/ramdisk/svn_trunk2/build/run_tests.py",
line 330, in _init_py_tests
svntest = importlib.import_module('svntest')
File "/usr/lib/python3.14/importlib/__init__.py", line
88, in import_module
return _bootstrap._gcd_import(name[level:], package,
level)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1406, in
_gcd_import
File "<frozen importlib._bootstrap>", line 1371, in
_find_and_load
File "<frozen importlib._bootstrap>", line 1335, in
_find_and_load_unlocked
ModuleNotFoundError: No module named 'svntest'
]]]
(I have also tried with the "out" directory under
svn_trunk2 but that had the same problem).
I think it's the regression from here:
https://lists.apache.org/thread/3s8d1t8r6x5d8xvvmqfqsfcm6fs1o56t
The rest - I think you do it right.
Ah, yes of course. I didn't connect the mental dots. Thanks!
I see Jun already committed this patch in r1936304 this morning,
with this the tests work.
I think that one should also be included in 1.15.0 - not
necessarily a release blocker but close to it - much of the
thunder from the CMake build is lost if the tests are unable to run.
CMake isn't really supported on anything but Windows, so making
this a release blocker would, IMO, require at least a discussion +
consensus here on dev@. I'm not happy that it's being somehow
gently ushered in as a replacement for autotools on those
platforms that support autotools. Suddenly making this failure
important (it's not a regression (tm)) is just way off the charts.
Well, I think it would be great to include it in the release anyway.
It doesn't really matter if we call it a "blocker" or not.
I suggest we nominate it and I'm pretty confident it'll get enough
votes to be merged before 1.15.0 is rolled.
Also what exactly do you mean by cmake not being supported on anything
but windows? It works fine on Unix and we have it as an option. Plus
the same bug occurs on Windows as well.
I meant the CMake /build/. I know it works on other platforms. So we'll
end up supporting CMake that "works everywhere" but is only needed on
Windows, and autotools that work much better than CMake on Unix-like
platforms.
I think it's a mistake to sink effort into making the CMake build appear
to work on platforms that don't need it, but I'm not maintaining or
using it, so... *shrug*
-- Brane
