Re: [PATCH v2] Makefile: make the "sparse" target non-.PHONY

On Thu, Sep 23 2021, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

On Thu, Sep 23, 2021 at 02:07:16AM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

We ensure that the recursive dependencies are correct by depending on
the *.o file, which in turn will have correct dependencies by either
depending on all header files, or under
"COMPUTE_HEADER_DEPENDENCIES=yes" the headers it needs.

This means that a plain "make sparse" is much slower, as we'll now
need to make the *.o files just to create the *.sp files, but
incrementally creating the *.sp files is *much* faster and less
verbose, it thus becomes viable to run "sparse" along with "all" as
e.g. "git rebase --exec 'make all sparse'".

OK. I think this solves the dependency issues sufficiently. It is a
tradeoff that you must do the normal build in order to do the sparse
check now. That is certainly fine for my workflow (I am building Git all
the time, and only occasionally run "make sparse"). I don't know if
others would like it less (e.g., if Ramsay is frequently running sparse
checks without having just built).

(I'd say "I do not care that much either way", but then I do not care
all that much either way about incremental sparse checks either, so I'm
not sure my opinion really matters).

My build procedure runs "make sparse" before the primary build,
simply because the former tends to be much faster to fail when there
is an issue in the code.  I can understand that depending on .o is a
cheap way to piggyback on the dependencies it has, but my latency
will get much slower if this goes in _and_ I keep trying to pick up
potentially problematic patches from the list.

Would you be OK with just running something like this instead?:

    make -j $(nproc) objects CC=cgcc CFLAGS="-no-compile -Wsparse-error -Wno-pointer-arith -Wno-memcpy-max-count"

It gives you almost exactly the same thing as the old "sparse" target. I
think the way it worked is really not something we needed a special
target for in the first place, or perhaps just a .PHONY alias.

The "almost" is because those -Wno-* are now per-file via
SP_EXTRA_FLAGS.

I.e. if we have a $(CC) that's willing to accept CC-like options but
just won't create output files we can use "objects" (or other targets I
added in 029bac01a87 (Makefile: add {program,xdiff,test,git,fuzz}-objs &
objects targets, 2021-02-23)). Even if the tool itself created broken
*.o files a change of $(CC) to the "real" compiler would ensure that
they'd get regenerated.