[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 005/143] meson: rename .inc.c files to .inc
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH 005/143] meson: rename .inc.c files to .inc |
Date: |
Fri, 7 Aug 2020 11:23:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 |
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.
> 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.
Paolo
- Re: [PATCH 007/143] tests/vm: do not pollute configure with --efi-aarch64, (continued)
- [PATCH 008/143] tests/vm: check for Python YAML parser in the Makefile, Paolo Bonzini, 2020/08/06
- [PATCH 009/143] configure: do not include $(...) variables in config-host.mak, Paolo Bonzini, 2020/08/06
- [PATCH 004/143] trace: switch position of headers to what Meson requires, Paolo Bonzini, 2020/08/06
- [PATCH 010/143] configure: expand path variables for meson configure, Paolo Bonzini, 2020/08/06
- [PATCH 005/143] meson: rename .inc.c files to .inc, Paolo Bonzini, 2020/08/06
[PATCH 011/143] configure: prepare CFLAGS/CXXFLAGS/LDFLAGS for Meson, Paolo Bonzini, 2020/08/06
[PATCH 013/143] configure: generate Meson cross file, Paolo Bonzini, 2020/08/06
[PATCH 014/143] build-sys hack: link with whole .fa archives, Paolo Bonzini, 2020/08/06
[PATCH 015/143] build-sys: add meson submodule, Paolo Bonzini, 2020/08/06