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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> >> 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).
> 
> Aside: As I recall you make a lot of use of ccache (as I do), so is the
> "meh" on incremental builds synonymous with it not being piped through
> $(CC) in this case?

I do use ccache, and yeah, it makes a big difference on incremental
builds of the actual object files. I don't use it for sparse, though (I
never really thought about it, but I don't see any reason why it would
not work?). Mostly I just don't run "make sparse" very often.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux