On Wed, Nov 03 2021, Jeff King wrote: > On Sun, Oct 31, 2021 at 02:00:42PM +0100, Ævar Arnfjörð Bjarmason wrote: > [...] >> I didn't notice before submitting this but this patch breaks the >> vs-build job, because the cmake build in "contrib" is screen-scraping >> the Makefile[1]. >> >> What's the status of that code? It's rather tiresome to need to patch >> two independent and incompatible build systems every time there's some >> structural change in the Makefile. > > My opinion when we took in the cmake topic was that it would be OK for > people working on the main Makefile to break cmake. It's an add-on and > the people who care about cmake are the ones who will do the work to > track the Makefile. > > But since there's a CI job that will nag you if it fails, that kind of > makes it everybody's problem in practice. That doesn't change my opinion > on how things _should_ work, but I have done small fixups as necessary > to stop the nagging. Yes, that was clearly the intent from reading the original discussion, but we've crept towards it being an actual hard dependency. I'd also be fine with some direction that just removed that vs-build/vs-test job to something optional... >> I hadn't looked in any detail at that recipe before, but it the vs-build >> job has a hard dependency on GNU make anyway, since we use it for "make >> artifacts-tar". >> >> So whatever cmake special-sauce is happening there I don't see why >> vs-build couldn't call out "make" for most of the work it's doing, isn't >> it just some replacement for what the "vcxproj" target in >> config.mak.uname used to do? > > The big question for me is whether that really is a hard dependency. > Obviously "make artifacts-tar" is for the CI job, but is the cmake stuff > supposed to work for regular users without relying on having GNU make at > all? I have no clue. It's a hard dependency for the job, since it tars up its built assets in the first step, and those are then unpacked and used in subsequent steps. It's being used to ferry the built binaries between CI phases. But yes, the intent was clearly to not have a dependency on GNU make, but as I argue in <patch-v2-3.3-cd62d8f92d1-20211101T191231Z-avarab@xxxxxxxxx> I think having those developers simply install it is better than forcing us to maintain two distinct and incompatible build systems. The selling point was that it was going to be really easy to maintain them in parallel, i.e. you'd just add a thing to a list here and a list there, but that assumes that nothing will ever structurally change in the Makefile. I think the other X-Y problem being solved there was that cmake has some better integration for Visual Studio somehow. I.e. it does what the "vcxproj" target in config.mak.uname does/did. I think that would be a fine use for cmake, and we can clearly accomplish that by having our cmake file effectively be a mostly thin wrapper for logic that lives in the Makefile. I.e. it would ask the Makefile what's in this list or other, what the CFLAGS are etc. etc., and feed that into relevant cmake variables. My patch starts us moving in that direction (but doesn't get anywhere close to that end-goal). I think if we did that the ~1k line CMakeLists.txt would be maybe 100-300 lines.
