Re: [PATCH 005/143] meson: rename .inc.c files to .inc

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 07/08/20 10:59, Peter Maydell wrote:
>> On Thu, 6 Aug 2020 at 20:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>> ---
>> What's the rationale for this ? ".inc.c" is the project's
>> standard naming convention for files which aren't headers
>> but which are lumps of C code #included into a top level .c
>> file. The .inc.c deliberately ends '.c' because that way
>> editors will use the right syntax highlighting for the file.
>
> Good point.  It can be changed to .inc.h too, if that's preferrable
> for you.

We have two types of inc files - the inline C sections but also .inc.h
files. I'm not sure they should be lumped together. I think most of the
header based ones are essentially templates which get expanded multiple
times with #undef/#define blocks before each inclusion.

>
>> It would be much better if Meson could cope with our
>> standard naming convention rather than forcing us to change it.
>
> First of all I need to describe why this is needed; it is because of the
> way Meson handles dependencies on generated headers.
>
> With Makefiles that have automatically generated dependencies, you
> typically make generated includes depend on the Makefile so that they
> are built before everything else and they are available when first
> building the .c files.
>
> Meson is similar, however the way it works is that you list those
> generated includes in the sources.  The dependencies are still
> automatically generated, but the build rules will ensure that the
> includes are generated before attempting to build the toplevel C sources.
>
> The problem is that Meson decides if something is a source vs. a
> generated include by looking at the extension: '.c', '.cc', '.m', '.C'
> are sources, while everything else is considered an include---including
> '.inc.c'.
>
> Going back to patch 124, I can now answer your question:
>
>>> It's not clear to me why all the decodetree lines ended up in a
>>> single "gen = []" block -- they're independent of each other.
>
> The files are added to the source list with "arm_ss.add(gen)".  All that
> line does is ensuring they are built before other target-specific files
> for ARM targets.
>
> The question then is if Meson could be changed to cope with our naming
> convention, and unfortunately the answer is no.  The root cause is that
> Makefiles list .o files (and uses implicit patterns to connect .o files
> to the corresponding sources), while Meson lists .c files.
>
> There is a silver lining, in that you do get something out of this: if
> you have a typo in the name of a .c file, it is detected it at
> "configure" time rather than having to wait until "make" tries to find
> the source code for that ".o" file.

Hmm - I guess one workaround is to tweak editorconfig so whatever we end
up renaming things still get identified as the right type of file for
syntax hi-lighting purposes.

-- 
Alex Bennée