[top-posting?]
On 25. 10. 2026 20:12, Daniel Sahlberg wrote:
Den tors 22 okt. 2026 kl 01:02 skrev Pavel Lyalyakin<[email protected]>:
Hello,
Following up on my related INSTALL email, here are two thoughts/proposals about
the minimum versions in the build systems:
1. Make minimum versions in the build systems consistent
I think that one set of minimum versions should be agreed upon and enforced in
both autoconf and CMake. As the vcproj build system is deprecated, updating it
isn't worth it IMHO.
Is it time to start ripping out support for vcproj in trunk, now that
we have a new minor release?
It would be nice. Removing all that extra complex generator magic would
be a good thing. And not trivial, since it implies cleaning
windows-specific things from build.conf as well.
On the topic of build systems: I would prefer to revert the CMake build
to be specific to just Windows and leave the autoconf build as the only
system on POSIX-like platforms – this includes WSL. Why? Because CMake
on *nix generates a different build than autotools on the same computer
and I'm not at all sure that the builds are even compatible between each
other.
2. Raise the minimum versions for some of the dependencies
As most of the minimum versions are 10 to 25 years old and are EOL, I think
that we might consider raising them in the future. Wouldn't it let simplify
some of the build and SVN code used for compatibility with certain old deps?
I would prefer to not raise requirements above what is supplied by
currently supported Linux distributions unless we have good reasons.
CMake 3.20 is a good example of this, there was something that was
significantly better with 3.20 and that version was supported on all
major platforms except RHEL 7. Since we can still build with autoconf
on RHEL 7 it was a good balance to update the minimum requirement.
I would be happy to for example require APR/APR-Util and httpd to a
somewhat modern version. Python 2 is another thing where we jump
through some hoops to support something which was EOL may years ago.
Agreed. We never had a policy to support only the latest and greatest.
These are *minimal* supported versions so that someone who wants to
build a recent Subversion release on an old computer can still do so. I
see no reason to change this policy. So it's a bit more work, for a bit
more good.
[...]
As for Python, configure accepts 2.7 and CMake accepts any 3.x, whereas INSTALL
says 3.6, which is what the test suite actually requires.
Python is an interesting case: For developers (i.e. autogen.sh and
tests), we require 3.6 and should really require 3.11 by now. But 2.7.18
should be supported by the Swig bindings. None of our build systems
actually distinguish between these two, it's a bit of a niche case.
[...]
-- Brane
