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?

>
> 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.

Kind regards,
Daniel


>
> Please let me know what you think.
>
> The following table shows the minimum versions in INSTALL and the *explicit* 
> version checks in each build system:
>
> +----------------+---------+----------+--------+---------+
> | Dependency     | INSTALL | autoconf | CMake  | vcproj  |
> +----------------+---------+----------+--------+---------+
> | APR            | 1.4     | 1.4      | -      | 1.4.0   |
> | APR-Util       | 1.3     | 1.3      | -      | 1.3.0   |
> | SQLite         | 3.24.0  | 3.24.0   | -      | 3.24.0  |
> | Serf           | 1.3.4   | 1.3.4    | 1.3.4  | 1.3.4   |
> | httpd          | 2.2     | 2.2      | -      | 2.2.0   |
> | LZ4            | r129    | r129     | -      | bundled |
> | zlib           | -       | -        | -      | 1.2.5   |
> | Cyrus SASL     | -       | -        | 2.0.0  | 2.0.0   |
> | gettext        | -       | -        | -      | 0.14.1  |
> | Python         | 3.6     | 2.7      | -      | -       |
> | SWIG           | -       | 1.3.40*  | -      | 1.3.25  |
> | SWIG, Python 3 | -       | 3.0.10   | 3.0.10 | 3.0.10  |
> | Perl           | -       | 5.8.0    | -      | -       |
> | Berkeley DB    | 4.0.14  | 4.0.14   | n/a    | 4.0     |
> +----------------+---------+----------+--------+---------+
>
> -       = no explicit check
> n/a     = not supported
> bundled = only the bundled copy is used
> *       = shows warning only
>
> The versions are from trunk: autoconf[1][2][3], CMake[4], vcproj[5].
>
> There are also restrictions that are *implicit*, i.e. the build systems 
> require a library without comparing version numbers. So although the build 
> systems don't check for an explicit minimum version, the version is still 
> enforced. AFAIK, this is true at least for Cyrus SASL (configure requires 
> libsasl2, so the version is at least 2.0) and for Python (CMake looks for the 
> Python3 CMake package).
>
> CMake doesn't check the versions of APR, APR-Util, SQLite and httpd. Only 
> vcproj checks zlib and gettext.
>
> 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.
>
> Thank you!
>
> [1]: https://svn.apache.org/viewvc/subversion/trunk/configure.ac?view=markup
> [2]: https://svn.apache.org/viewvc/subversion/trunk/build/ac-macros/
> [3]: 
> https://svn.apache.org/viewvc/subversion/trunk/build/find_python.sh?view=markup
> [4]: https://svn.apache.org/viewvc/subversion/trunk/CMakeLists.txt?view=markup
> [5]: 
> https://svn.apache.org/viewvc/subversion/trunk/build/generator/gen_win_dependencies.py?view=markup
>
> --
> With best regards,
> Pavel Lyalyakin

Reply via email to