On Sun, 19 Jul 2026 at 20:03, Daniel Sahlberg <[email protected]> wrote:
> Den lör 18 juli 2026 kl 15:16 skrev Branko Čibej <[email protected]>: > >> 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 >> >> > I see no voices saying we should keep vcproj. Some have been suggesting a > more agressive removal strategy and some a lighter touch. I believe have > consensus on the removal and I think declaring deprecation now should be a > nice middle road. I've tried to write up something in the draft release > notes (and Nathan has checked my language - thanks!). > > I have removed vcproj/vcxproj support in r1940037. -- Ivan Zhakov
