On 18. 7. 2026 14:26, Timofei Zhakov wrote:
On Thu, Jul 16, 2026 at 11:22 PM 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, I think it's time for it to go.
I'm on SIGKILL rather than SIGTERM squad :)
As Ivan summarised the reasons, plus many small notices on-list
throughout the days, I don't have much to add. It becomes a debt to
maintain. I don't see how vcxproj support is used in the long run.
Also a few points from Brane's reply (quoting is messed up, sorry):
> 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. :)
Ye, that is the idea that cmake is more like autoconf, aiming to
repeat it as much as possible. I see nothing wrong with it.
> 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.
But maintaining both has its costs. Not saying we can't do that but
I'd rather spend time doing something useful than fixing a build
system that we don't want people to use in the future anyway.
I was being pedantic. The argument was "removing this ... allows that"
without mentioning effort conflicts. Of which there are few, as far as
I'm aware, very little effort has been spent on maintaining the vcxproj
build. That no-one has /wanted/ to maintain it is neither here nor there. :)
If we're debating, let's be precise. It's more honest to say, "let's
remove this because I don't like it" than invoking a non-existent conflict.
I mean, I'd love to remove all this Windows support mess, I don't like
it at all ... even remove Windows from this reality altogether. One can
dream, right?
-- Brane
