18.10.2022 00:17, Michael Biebl wrote:
..
Patching the upstream provided .pc file in Debian feels odd, tbh.
Are you sure Requires.private is only relevant for static linking? Isn't this
what Libs.private is for.
Yes it feels odd indeed. The problem here is often due to lack of
understanding how the .pc files work, which parts should go where.
Myself I don't know either how it should be done. I asked about this
several times in different places but each time the answers were
different. So I ended up working in case-by-case basis: when a .pc
file gets new Libs.private or Requires.private, I evaluate how this
new library is actually being used, - and in all cases so far it was
entirely internal thing not exposed in any way to the users of the
said library, *unless* we want static linking (where regular debian
shlib mechanism does not work, obviously).
Here's just one example of this in one of my packages:
https://salsa.debian.org/qemu-team/spice/-/blob/master/debian/rules#L31
(this one comes from #803926)
Neither includes nor dynamic libs are needed to build stuff with
libsamba-server, the only case where it's needed is when we try to
build something statically, so that all libraries used by (non-existing
by now) libspice-server.a are needed during link time.
At least once I come across a case where pkgconfig --cflags were
actually needed - because this library's header file actually
included some other header file.
18.10.2022 05:27, Adrian Bunk wrote:
> The same command with all packages installed outputs:
>
> $ pkg-config --cflags virglrenderer
> -I/usr/include/virgl -I/usr/include/libdrm
> $
>
> This would be required if headers under /usr/include/libdrm were
> included by /usr/include/virgl/virglrenderer.h, but that isn't
> the case.
Exactly. And this is the case in many other situations too (eg my
spice example above).
In this very case, all extra dependencies are config-time stuff
internal to virglrenderer, it does not change abi/api of its users.
It is just that virglrenderer will be able (or not) to use extra
features when asked. Even the header files with available
options aren't being generated at build time, - it will return
ENOSYS-like error at runtime when asked for an optional feature
which is not compiled in. The interface of the library does not
change in any way.
I just don't know how it *should* be done. Maybe pkgconfig should
not insist on something.private when asked for cflags?
Thanks,
/mjt
