Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > In this case I do think the change is justified. I've personally got a > few local topics that I keep having to (even with rerere) solve > conflicts for due to this list of files, and Junio deals with the same. > > Ditto for some of the changes I've made recently to make things > non-.PHONY. That's resulted in major workflow improvements for me, To me, I haven't noticed any workflow improvements for me, so I do not see how my name got into the sentence. > But in any case, the selling point of the original cmake integration was > not something to the effect of: > > "nobody should have to change this in anything but ever so this > re-implementation is a one-off" I agree that this wasn't how it was sold, but ... > But rather something like: > > "This re-implementation is a one-off, but any updates to both should > be trivial." ... I do not think this was how it was sold, either. As far as I recall, it was rather: this may double the maintenance burden, but the reward to help casual Windows builders is large enough that those who want to add the CMake support are willing to bear their share of the burden. > As someone who's had a couple of recent run-ins with cmake I can tell > you it's really not trivial at all. Surely. > So given that the selling point of the original change didn't turn out > as was expected I think it's fair to re-visit whether we'd like to take > this path going forward, or to choose another trade-off. OK. The rest of the message I am responding to is your revisiting, I guess. >> The entire point of the CMake configuration is to allow developers on >> Windows to use the tools they are used to, to build Git. And believe it or >> not, GNU make is not one of those tools! I know. Very hard to believe. :-) > > I believe that, the question is why it isn't a better trade-off to just > ask those users to install that software. Our Windows CI is doing it > on-the-fly, so clearly it's not that hard to do it. > > Note that I'm not saying that whatever integration those users get in VS > from the special-cause CMake integration should change. We're only > talking about it invoking "make" under the hood in a way that'll be > invisible to the user. > > POSIX "sh" isn't native to Windows either, and that CMake file invokes > shellscripts we ship to e.g. build the generated headers, so this > workflow is clearly something that's OK for an end-user once the one-off > hassle of installing a package is over with.
