Re: [DTrace-devel] [PATCH 0/9] relocatable DTrace

[Nick Alcock <nick.alcock@oracle.com>]

On 31 Jul 2024, Kris Van Hees said:

> General comments because my review covers the entire series...
>
> Why are there two pkg_config files being introduced when it seems like a
> single dtrace.pc one would be sufficient.  The dtrace utility is used both
> for tracing and for the building of libraries and executables with USDT
> probes,  I see no reason why a single dtrace.pc couldn't cover both.

Simply because there are two distinct use cases here that require a
different set of libraries and headers from different places: "we want
to use USDT using <sdt.h>", and "we are a DTrace consumer". Almost
nothing wants both, only one wants a library, etc etc.

Bear in mind that more-or-less universal usage of pkg-config (as in,
with CMake, Autoconf and Meson it is hard to impossible to do anything
else) has the caller appending $(pkg-config --cflags $pkg) to CFLAGS or
CPPFLAGS and $(pkg-config --libs $pkg) to LIBS. If we tried to use the
same pkg-config file, this would mean that *raw USDT probe users* would
find themselves linking with libdtrace! This is *surely* not what we
want.

pkg-config is not meant to be "one pkg-config file per package", despite
the name: a huge number of packages have multiple. (The worst offender
on my system appears to be Qt 6, with 136, but even a simple thing like
xcb-util has four.)

> On that note, why can't pkg-config then also be used as a means to get the
> location of the dtrace executable?  Why go through the trouble of performing
> text substitution on runtest.sh to insert the location of dtrace when you
> already use pkg-config in it to get the appropriate include directory for
> the installed case.

Because I didn't think of it. That's an excellent idea. Adjusting
accordingly. Will send a v2 of the whole series (because it's been
ages).

> I think this series needs to be reworked to be consistent.  If we are going
> to use pkg-config, then let's use it to its fullest extent rather than using
> it for some stuff but then still hardcoding other things.  That makes no sense
> to me.

Agreed. Anything else you can think of that's hardcoded? I can't
immediately think of anything (because we can't use pkg-config in
dtprobed.service, it's not a program) but you looked at this much more
recently than me...