Re: Target-dependent include path, why?

[Paolo Bonzini]

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.

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

Thanks,

Paolo

[1] there is the gnutls issue on macOS, but IIRC the dependency CFLAGS 
are just the manifestation of a bug somewhere else that I forgot the 
details about (the Meson issue tracker and wiki page has the info, I'll 
get back to it some day).  This bug only affects gnutls because we do 
tend to "#include <>" in .c files only, and did so even before the 
switch to Meson.