On Tue, Sep 28 2021, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> I.e. per [2] want "make <file>.sp" to *always* run "sparse", even
>> though a corresponding "make <file>.o" would only re-run the "real"
>> compilation if needed.
>
> It is different from my reading. If <file>.c and what it includes
> haven't changed, it would be fine not to run "sparse".
I was attempting to summarize this part of Ramsay Jones's comments in
[...] Prior to this patch series, 'make <file>.sp' would _always_
run sparse over the file - it would not depend on the 'mtime' or
existence of any other file, or run the compiler (and wouldn't leave
any 'droppings' either). I liked that! :D
> The point of
> running "make <file>.sp" is to see it fail if there is something
> problematic. If there is any room for the word "*always*" to come
> into the observation, it would be more like "if we cannot make it
> follow the usual dependency rules like the real compilation, we can
> live with it always running, as it is fast enough". If we can make
> it honor the dependencies, that would give the best of both worlds,
> and we do not have to add an extra target.
...which I think describe something different than what you're
describing here.
I.e. I was under the impression that you didn't mind the incremental
part of it (but Ramsey did), but just didn't want the initial "make
sparse" to take much longer due to the *.o file compilation.
In any case, we can always tweak the "make <file>.sp" later. I don't
mind it working the way it did before, I think the only time I ever make
individual files is when generating the assembly output for them. So as
long as I've got a "make sparse-incr" target I can use.
Do you think that approach in this v4 is OK to move forward?
