Re: Target-dependent include path, why?

[Peter Maydell]

On Fri, 9 Dec 2022 at 17:42, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 12/9/22 17:52, Peter Maydell wrote:
> >> Dependencies are usually added near the .c files that use them.  That's
> >> a bit messy of course if you have an "#include <>" in a heavily-included
> >> QEMU header.  You can consider it a way to discourage heavily-included
> >> headers.
> > This has always seemed to me to be a recipe for bugs that only
> > show up in the uncommon case of "some dependent library's
> > header files have been installed somewhere other than in
> > a system include directory". Is it possible to get meson to do
> > things the more standard way, where if a binary has a dependency
> > declared then the CFLAGS for that dependency get used for all
> > objects that go into it?
>
> This *is* what Meson does, it's QEMU that has always done non-standard
> things in order to share the .o files for target-independent sources.
> Back in the day is was -Wl,--whole-archive, then it became foo-obj-y.
> Now it's foo_ss but it's the same thing as foo-obj-y in the end.
>
> Once the relation between objects and binaries becomes many-to-many, you
> can't really apply "the CFLAGS for the binaries' dependencies" to all
> the objects.  Pre-Meson, there were three ways to declare dependencies:
>
> - placing pkg-config output directly in $(QEMU_CFLAGS) and $(LIBS).
> This caused binaries to have unnecessary dependencies at times.

Yeah, this is what I think of as "the standard thing".

> - mentioning dependencies in $(obj)/foo.o_{CFLAGS,LIBS} or something
> like that, declaring dependencies in objects and applying them to
> binaries.  The Makefile implementation was very buggy.
>
> - a mix of the two, with the include path added to QEMU_CFLAGS and a
> target variable definition "foo$(EXESUF): LIBS += ..." that avoided the
> unnecessary dependencies.
>
> The sourceset thing was added to Meson specifically for QEMU, inspired
> by the second option.  Without the bugs[1], everything could become
> fine-grained.  Only glib stayed in QEMU_CFLAGS (the third option);
> anything else was unnecessary because everything includes glib.h through
> osdep.h anyway.
>
> The closest thing to what you're suggesting is to keep LIBS fine-grained
> while making CFLAGS coarse-grained, i.e. the third option above.  That
> is what the patches I sent today do when moving the glib tests to Meson,
> so it is not hard to expand it to other dependencies; but while it might
> avoid the gnutls issues, it will probably cause other issues---think of
> SDL messing with "#define main".  Overall, I'm not sure it's a win.

The thing I find counterintuitive about what we have currently
is that I can add a #include of a QEMU-internal header to a
source file, and now the build can be broken on some host
system configurations.

I'd be happier with either:
 (1) it's always safe to #include QEMU's own headers in its
     source files
 (2) sometimes a new QEMU header #include requires you to add a
     dependency to a meson.build file, but if you forget to do
     this then the build reliably fails on *all* host systems

thanks
-- PMM