Re: Dropping vcproj [Was: Subversion 1.15.0-rc3 up for testing/signing]

On 18. 7. 2026 00:51, Ivan Zhakov wrote:
> On Fri, 17 Jul 2026 at 00:23, Daniel Sahlberg 
> <[email protected]> wrote:
>
>     Den ons 15 juli 2026 kl 14:58 skrev Ivan Zhakov <[email protected]>:
>     ...
>
>
>         Also I think we should drop support vcxproj support in the
>         long term.
>
>
>     Agree. I would support a decision to announce it as deprecated and
>     planned for removal in a subsequent release. The reason for
>     deprecating and not just removing it is that it is currently a
>     functional build system and it might disturb downstream users if
>     we just remove it.
>
>     Can we reach consensus on a decision already before the release of
>     1.15?
>
> +1 for announcing vcxproj as deprecated and planned for removal in a 
> subsequent release.
>
> Some more datapoints in support of this:
>
> 1. The vcxproj-based build is conceptually different from CMake and 
> autoconf. In practice, we are maintaining two similar build systems 
> plus the entirely separate one in form of vcxproj.

We are maintaining three different build systems, there's no need to 
embellish. We maintained two until CMake came along. If we stretch the 
definition of "similarity" to make the CMake build similar to the 
Autoconf build, then I'll have to double-check we're not implementing 
Subversion in Go or some such. :)


> 2. Supporting vcxproj makes some improvements around the CMake build 
> noticeably harder to implement. For example, running tests via 
> win-tests.py would currently require two side-by-side/conditional 
> implementations.

That's just the normal cost of deciding to support a third build system. 
Where does it say that one should run tests built by CMake through 
win-tests.py? I thought the idea was to make win-tests.py redundant.


> 3. Removing vcxproj support on trunk would let us finish remaining 
> work for CMake to reach parity with autoconf. Which would then allow 
> us to declare CMake the default in 1.16.

That's a red herring. Nothing in the vcxproj build is blocking anything 
in CMake land. They are, as you note yourself, completely different 
build systems.


Don't get me wrong, I'm for reducing the number of build systems we 
support. But thes arguments are weak at best.

-- Brane