Re: [PATCH] Makefile: replace most hardcoded object lists with $(wildcard)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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@gmail.com> 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.