On Wed, 4 Nov 2026 at 17:53, Branko Čibej via dev <[email protected]> wrote:
> 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. > Actually not that much can be removed: 1. 'msvc-delayload' option: I have removed it in r1940039. 2. 'msvc-fake' option: I have removed it in r1940040. 3. 'msvc-name' option: I have removed it in r1940041. 4. TargetLib.disable_shared() and TargetSWIGLib.disable_shared() methods: I have removed them in r1940042. > Or is the CMake build using those? > > There are several Windows specific options that there are still in use: 1. 'msvc-exports': list of headers files to generate module definition file (.def) with exported functions. It seems they should stay. 2. 'msvc-libs': additional list of Windows system libraries to link. Probably we can replace them with externals targets. Like we do for other dependencies. But I am not sure it's worth it. 3. 'msvc-static': forces target to build as static library. Currently only used for libsvnxx and libsvn_test. I do not what was the reasons to force them to be static. Maybe we can remove it. -- Ivan Zhakov
