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. -- Timofei Zhakov
