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
