From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH 0/9] relocatable DTrace
Date: Thu, 01 Aug 2024 17:45:21 +0100 [thread overview]
Message-ID: <87sevojiou.fsf@esperi.org.uk> (raw)
In-Reply-To: <ZqqaYbavY9AMUiEP@oracle.com> (Kris Van Hees's message of "Wed, 31 Jul 2024 16:11:13 -0400")
On 31 Jul 2024, Kris Van Hees outgrape:
> On Wed, Jul 31, 2024 at 08:54:44PM +0100, Nick Alcock wrote:
>> 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.
>
> If people do that without actually checking whether it makes any sense, then
> that would be an argument (to me) to not use pkg-config at all. Using
> pkg-config to get --libs when there is no library to link with is pointless
> and merely shows that the person using this has no diea what they are doing.
Agreed. If someone is putting the pkg-config files somewhere unusual,
it's because they have *already* pointed pkg-config at that new place,
so we can rely on pkg-config still working.
We can handle people changing --prefix alone (the overwhelmingly common
case) by setting the pkg-config path to "../../../share/pkgconfig" :)
> The cflags argument I can accept, but then perhaps we need *3* pkg-config
> files?
No need.
> What exactly do we need this for? Testsuite needs to know where to
> find dtrace, so that could need a pkg-config file. Anyone wanting to use
> libdtrace would need to know where to find the library and what cflags to
> use (finding the include files), which would need a pkg-config file. And
> compiling code with SDT would need another pkg-config file.
We need two -- one for consumers (which need to know where dtrace.h and
libdtrace are) and one for sdt users (which need to know where sdt.h
is). We can just add the dtrace= variable pointing at the executable to
both: either might potentially find it useful to know that, and an
unused variable in a pkg-config file is harmless.
--
NULL && (void)
prev parent reply other threads:[~2024-08-01 16:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 18:59 [PATCH 0/9] relocatable DTrace Nick Alcock
2024-05-31 18:59 ` [PATCH 1/9] spec: install sdt*.h in /usr/lib64/dtrace/include/sys Nick Alcock
2024-05-31 18:59 ` [PATCH 2/9] build: initial pkg-config support Nick Alcock
2024-05-31 18:59 ` [PATCH 3/9] build: track configured vars Nick Alcock
2024-05-31 18:59 ` [PATCH 4/9] build: --bindir is supposed to be equivalent to --sbindir Nick Alcock
2024-05-31 18:59 ` [PATCH 5/9] build: the TESTDIR is relative to the LIBDIR by default Nick Alcock
2024-05-31 18:59 ` [PATCH 6/9] build: add a pkg-config file for dtrace consumers: use it Nick Alcock
2024-05-31 18:59 ` [PATCH 7/9] tests: delete the kernel build dir stuff Nick Alcock
2024-07-31 19:22 ` [DTrace-devel] " Kris Van Hees
2024-07-31 19:32 ` Nick Alcock
2024-05-31 18:59 ` [PATCH 8/9] build: make dtrace and dtprobed relocatable Nick Alcock
2024-05-31 19:46 ` [DTrace-devel] " Nick Alcock
2024-05-31 18:59 ` [PATCH 9/9] test: work when relocated Nick Alcock
2024-07-31 19:21 ` [DTrace-devel] [PATCH 0/9] relocatable DTrace Kris Van Hees
2024-07-31 19:54 ` Nick Alcock
2024-07-31 20:11 ` Kris Van Hees
2024-08-01 16:45 ` Nick Alcock [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sevojiou.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=kris.van.hees@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.