On 4. 11. 2026 17:29, Ivan Zhakov via dev wrote:
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.
Still needs cleanup of windows-specific constructs in build.conf. Or is the CMake build using those?
-- Brane
