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

[Peter Maydell]

On Fri, 7 Aug 2020 at 10:23, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> 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.

Not really, though I guess it's slightly better than plain .inc.
They're not header files...

> > 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.

But we don't really want to build all these files before building
all C sources. We just want to say "this .c file depends on these
.inc.c files" and then let the build tool figure it out, surely?

> 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'.

Is this hardcoded in Meson? That seems pretty suboptimal.

> 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.

Do you mean that it just adds an extra implicit ordering constraint,
such that if we need to rebuild both files not in 'gen' and files
that are in 'gen' the 'gen' ones go first, or that Meson really
builds all the 'gen' files first? What happens when you edit a
.decode file? How much stuff gets rebuilt?

> 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.

Can Meson handle "this .c file needs to be built from something else?".
Presumably so, that's a common pattern for flex/yacc type tools.

thanks
-- PMM