Paolo Bonzini <pbonz...@redhat.com> writes:
> On 07/08/20 10:59, Peter Maydell wrote: >> On Thu, 6 Aug 2020 at 20:25, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> Signed-off-by: Paolo Bonzini <pbonz...@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
