[DTrace-devel] [PATCH 1/5] build: overridable configuration variables

Nick Alcock nick.alcock at oracle.com
Fri Jan 26 13:50:53 UTC 2024


On 21 Dec 2023, Kris Van Hees uttered the following:

> On Wed, Nov 29, 2023 at 04:08:25PM +0000, Nick Alcock wrote:
>> The Makeconfig checks are purely compile-time, so should always work: but if
>> they don't, it is sometimes desirable to be able to override them.
>> 
>> This change causes every check-* invocation in Makeconfig to respond to
>> HAVE_* make variables set on the command line, and also to produce a line in
>> 'make help' of the general form
>> 
>> HAVE_LIBSYSTEMD=[yes/no]	Override check for presence of sd_notify in libsystemd
>
> The way you automated this results in rather odd help output because the
> automated help output of course fails to capture the nuances of the tests they
> represent.
>
> E.g. HAVE_LIBFUSE3 is about whether fuse2 or fuse3 is used, but it is reported
> as:
>
> 	Override check for presence of fuse_session_receive_buf in libfuse3
>
> Likewise, HAVE_SYSTEMD and HAVE_LIBCTF are about existance of libraries even
> though the test is based on a specific symbol.

I thought about this, but I'm fairly sure that if the test spuriously
fails because that symbol is removed for some reason, the user would
like to know what was actually being checked for. (Autoconf-generated
configure output says what symbol is being checked for for the same
reason. cmake doesn't and it is so *very* unpleasant to figure out what
the hell it was actually checking for when it goes wrong.)

> But HAVE_FUSE_LOG etc *are* about specific functions, but then HAVE_CLOSE_RANGE
> specifies specific arguments in the help output?

I've chopped those out with a regex: as you noted elsewhere, they look
downright weird and are unnecessary for the purpose of figuring out what
the heck it's looking for.

> I think sometimes automation is not our friend.  It might be better to just
> write a help line for each override that clearly explains what it means.

... maybe? I have some sunk cost fallacy here distorting my perspective :)

-- 
NULL && (void)



More information about the DTrace-devel mailing list