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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox