Re: [PATCH 0/3] Makefile: make "sparse" and "hdr-check" non-.PHONY

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

On Wed, Sep 22 2021, Junio C Hamano wrote:

> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
>
>>>> At the heart of my unease is dependencies (or rather the lack) for
>>>> the 'synthetic object files' *.hco and *.sp. (Also, the addition
>>>> of even more 'shrapnel' to the build directories - I wrote a patch
>>>> to remove the useless *.hcc files just after commit b503a2d515e was
>>>> included, but didn't get around to submitting it).
>>> 
>>> I don't consider them shrapnel if they're holding useful results. :)
>>
>> Heh, yes I am a bit of a curmudgeon! :D
>
> We do not necessarily have to have these files immediately next to
> the corresponding source file.
>
> For example, we could give .shrapnel/ hierarchy to *.hco and *.sp
> files, so that for revision.c and compat/bswap.h, we'd create
> .shrapnel/revision.sp and .shrapnel/compat/bswap.hco files that will
> not be so cluttering ;-)

I've got some WIP efforts in other areas to do that for some other
rules.

The problem is that you need to "mkdir .shrapnel" to create a
".shrapnel/revision.sp". So you need the ".shrapnel/revision.sp" to
depend on the ".shrapnel".

Except you'll find that the naïve implementation of that fails, since
any file you create will bump the mtime of the containing directory, so
you'll keep re-making ".shrapnel/revision.sp" because ".shrapnel"
changed, because ".shrapnel/revision.sp" changed...

This is why we have the "missing_dep_dirs" hack for
"COMPUTE_HEADER_DEPENDENCIES" in the Makefile, i.e. we'll make the
directory, but only if it doesn't exist, we bypass the normal "make"
dependency mechanism.

Another way to deal with it is to have say a
build-stuff/dropit-here/file.gen that you build from a top-leve file.c,
then depend on a "build-stuff", that does a "mkdir -p
build-stuff/dropit-here", I used that trick in another case where the
file.gen were not nested.

But for creating subdirs etc. you'll quickly get into a lot of
nastyness, which I'd prefer to just avoid here.

We already have e.g. the *.hcc files, let's leave generating these on
the side somewhere to some more general topic, which could also move the
*.o files out of the top-level if we're caring about the cleanliness of
the top-level directory.