On 19. 7. 2026 17:22, Jun Omae wrote:
On Mon, Jul 20, 2026 at 12:03 AM Branko Čibej<[email protected]> wrote:
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
The cmake builds for swig-py, swig-rb and javahl do not work on all platforms.
The ctest and install for swig-py, swig-pl, swig-rb and javahl do not
work on all platforms.
I'm currently working cmake (with ctest and install) for swig-* on all
platforms, and will push the changes later.
The CMake build doesn't even support Keychain on macOS as far as I can see.
-- Brane
