Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 6, 2022, 10:57 UTC
Message-ID: <221206.865yeodbtg.gmgdl@evledraar.gmail.com>
In-Reply-To: <30360f4c-91a5-177b-133f-eb7036ed676a@dunelm.org.uk>

On Tue, Dec 06 2022, Phillip Wood wrote:

Show 29 quoted lines

> On 06/12/2022 03:52, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> 
>>> Just to add my own digression: I asked in some past thread (which I'm
>>> too lazy to dig up) why it was the cmake file couldn't just dispatch to
>>> "make" for most things.
>
> Because make is not installed by default on Windows. Our CI job uses
> msbuild (whatever that is) and when I was playing with Visual Studio 
> last week it was using ninja.
>
>>> I.e. it needs to at some level be aware of what it's building for the
>>> IDE integration, but for say making a "grep.o" there's no reason it
>>> couldn't be running:
>>>
>>> 	make grep.o
>>>
>>> Instead of:
>>>
>>>          cc <args> -o grep grep.c [...]
>>>
>>> which requires duplicating much of the Makefile logic (possibly with
>>> some Makefile shim to not consider any dependencies in that case).
>> That leads to a question at the other extreme.  Why does any logic
>> in CMakeLists.txt even have to exist at all?  Whenever it is asked
>> to make foo, it can be running "make foo" instead of having its own
>> logic at all.  ;-)
>
> Yes, if make was available then we wouldn't need to use CMake.

I think Junio and I are talking about something slightly different. Yes "make" isn't available by default. Getting it requires installing a larger SDK.

But if you look at the history of contrib/vscode/README.md in our tree you'll see that we used to support this "Visual Studio Solution" for years via GNU make, it probably still works.

The change in 4c2c38e800f (ci: modification of main.yml to use cmake for vs-build job, 2020-06-26) shows when the CI was switched over to using cmake instead.

The code to support that is still in-tree as the "vcxproj" target in "config.mak.uname", which calls out to the ~1k lines of Perl code in contrib/buildsystems/Generators/*.

I'm not suggesting we go back to that. The question is whether the trade-off of supporting an entirely separate build system without a GNU make dependency was worth it.

On the one hand those developing on Windows don't need to install it as a package, on the other hand we end up spending more developer time in writing duplicate build logic.

The advantage of cmake is that it knows how to generate all that VS-integration XML etc., so as soon as it knows how to build Git you get that for free.

But I think you can get that while not having a "real" cmake recipe, but just a thin shim for calling out to the Makefile.

Is such a thing a hack? Yes. Is it silly to e.g. build with "ninja" and really have it just shell out to "make"? Yes.

But it might still be worth it if we judge that the goal of getting that VS integration is sufficient. And that we're not willing to absorb the cost of maintaining two distinct build recipes in perpetuity.