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

[Paolo Bonzini]

On 07/08/20 11:30, Peter Maydell wrote:
> 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...

Ok for the lack of a better option I'll switch.

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

With Makefiles we have two options:

1) build before everything, e.g.

linux-user/x86_64/Makefile.objs
        generated-files-y += linux-user/x86_64/syscall_nr.h

The way it works is that, by building the generated files first, we can
then rely on automated dependency tracking.  It is most useful for files
that are included widely, such as header files.


2) fine-grained dependency, e.g.
        target/arm/translate.o: target/arm/decode-neon-shared.inc.c

This needs no explanation.  It is most useful for files that are
included only once or twice, such as .inc.c files.


With Meson you have only one choice and it is a third option, namely
"build at the beginning of the corresponding target"; the way you
express it is to list the includes in the sources of that target.

The rationale is the same as (1); in terms of what is rebuilt when it is
the same as (2).  It may remove a bit of parallelism: if you edit
helper.c and insns.decode, however, helper.c won't be built until after
decode-insns.inc is created.

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

Yes, it is.  It is certainly a different mindset not being able to
control every aspect of the build.  On the other hand surprises are rare.

>> The files are added to the source list with "arm_ss.add(gen)".  [...]
>> 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?

Only what's needed.

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

Yes, of course (we have cases of that, for example with QAPI sources).
Generated sources that are top-level (not includes) also don't hamper
parallelism of the build in any way.

Paolo