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!). Cheers, Daniel
