Jeff King <peff@xxxxxxxx> writes: > On Wed, Mar 06, 2019 at 12:23:20AM +0000, Ramsay Jones wrote: > >> > Yeah, that's what I was hinting at earlier in the thread. Here it is >> > sketched out to an actual working patch. The sub-make bits could >> > actually be a shell script instead of a Makefile; the only point in >> > using make is to use the parent "-j" for parallelism. >> >> sigh. :( >> >> I wish my patch removing this target had been picked up now! >> >> Earlier this evening I spent an hour or so writing an email which >> tried to discourage spending any time on this, because of the >> potential for this to be a huge time-suck. An unrewarding one at >> that! :-D > > Heh. I am OK with removing it, too. FWIW, I am fine with that plan as well. > My thinking earlier in the thread was that it should go in our bag of > linting tools that people should generally run. But actually, it is kind > of expensive to run, and it does not actually help anything immediately > in practice. I.e., what we really care about is that the C source files > compile, and running "make" does that (and especially running it on > various platforms). This is just checking for a _potential_ problem if > somebody were to include a particular header file at the start of > another C file. > > So it's really about 2 steps removed from stopping an actual problem. Yeah, exactly. > diff --git a/compat/bswap.h b/compat/bswap.h > index 5078ce5ecc..e4e25735ce 100644 > --- a/compat/bswap.h > +++ b/compat/bswap.h > @@ -1,3 +1,6 @@ > +#ifndef COMPAT_BSWAP_H > +#define COMPAT_BSWAP_H > + > /* > * Let's make sure we always have a sane definition for ntohl()/htonl(). > * Some libraries define those as a function call, just to perform byte > @@ -210,3 +213,5 @@ static inline void put_be64(void *ptr, uint64_t value) > } > > #endif > + > +#endif /* COMPAT_BSWAP_H */ This probably is worth having as an independent clean-up.
