[DTrace-devel] [PATCH 5/5] build: add configure script

[Nick Alcock]

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

> On Wed, Nov 29, 2023 at 04:08:29PM +0000, Nick Alcock wrote:
>> +write_config_var()
>> +{
>> +    local val="$(printf "%s" "$2" | sed 's,^.*=,,')"
>> +
>> +    if [[ ! -d build/.config ]]; then
>> +       mkdir -p build/.config
>> +       touch build/.config/dir.stamp
>> +        echo 'Writing build/config.{h,mk}'
>
> This is a confusing message because it is not accurate.  The script is actually
> writing to build/.config/config.$1.{h,mk}.

Yes, but those trigger build/config.{h,mk} regens, and those are the
only things users should ever need to look at. The .config stuff is just
an internal implementation detail to avoid unnecessary re-executions in
the makefile itself. (Hence the use of a .-prepended hidden file name.)

>> +    fi
>> +
>> +    case $val in
>> +        no) printf '# HAVE_%s undefined\n' $1 > build/.config/config.$1.mk
>> +            printf '/* #undef HAVE_%s */\n' $1 > build/.config/config.$1.h;;
>> +        yes|'') printf 'HAVE_%s=y\n' $1 > build/.config/config.$1.mk
>> +                printf '#define HAVE_%s 1\n' $1 > build/.config/config.$1.h;;
>> +    esac
>> +}
>> +
>> +rm -f build/config-vars.mk
>> +rm -rf build/.config
>
> This is problematic because if I simply want to invoke configure --help to get
> the help output, I do not necessarily want my previous config to get deleted.
> Surely, some options like --help should *not* have any side effects like that.

True! Didn't think of that.

> In fact, ideally, I would prefer a failed configure run (if that is in fact
> even possible with this tiny script) to leave any previous config in place.

Hm. We can fail (via set -e). We should emit to new files, then mv them
over the real ones at the last minute (and delete the temps in an ERR
trap). Adjusted.

(This also avoids the problem that led to us having to do the rm -fs, so
they're gone too.)

> I.e. only replace any existing config if configure is successful.
>
> Right now, nothing that I see can cause a failure - which is also interesting
> because that means if I have something wrong in my tree and e.g. config-vars.mk
> is not writable, it does not seem an error will be reported.

We are running under set -e, so failures are possible from almost
anywhere :)

> obviously, the rm statements above would yield an error but since they really
> shouldn't be there IMHO, once they are removed, failing commands do not seem
> to be considered - i.e. no error checking.

set -e handles that for us :)

>> +for option in "$@"; do
>> +    case "$option" in
>> +        --help) help; exit 1;;
>> +	--prefix=*) write_make_var prefix "$option";;
>> +        --objdir=*) write_make_var objdir "$option";;
>> +        --libdir=*) write_make_var LIBDIR "$option";;
>> +        --bindir=*) write_make_var BINDIR "$option";;
>> +        --sbindir=*) write_make_var SBINDIR "$option";;
>> +        --includedir=*) write_make_var INCLUDEDIR "$option";;
>> +        --udevdir=*) write_make_var UDEVDIR "$option";;
>> +        --systemd-unit-dir=*) write_make_var SYSTEMDUNITDIR "$option";;
>> +        --docdir=*) write_make_var DOCDIR "$option";;
>> +        --mandir=*) write_make_var MANDIR "$option";;
>> +        --testdir=*) write_make_var TESTDIR "$option";;
>> +        CC=*) write_make_var CC "$option";;
>> +        CPP=*) write_make_var PREPROCESS "$option";;
>> +        CFLAGS=*) write_make_var CFLAGS "$option";;
>> +        CPPFLAGS=*) write_make_var CPPFLAGS "$option";;
>> +        LDFLAGS=*) write_make_var LDFLAGS "$option";;
>> +        BPFC=*) write_make_var BPFC "$option";;
>> +        BPFCPPFLAGS=*) write_make_var BPFCPPFLAGS "$option";;
>> +        BPFCFLAGS=*) write_make_var BPFCFLAGS "$option";;
>> +        BPFLD=*) write_make_var BPFLD "$option";;
>> +        --user-uid=*) write_make_var USER_UID "$option";;
>> +        --dumpcap-group=*) write_make_var DUMPCAP_GROUP "$option";;
>> +        --unpriv-uid=*) write_make_var UNPRIV_UID "$option";;
>> +        --unpriv-home=*) write_make_var UNPRIV_HOME "$option";;
>> +        --kernels=*) write_make_var KERNELS "$option";;
>> +        --kernel-mod-dir=*) write_make_var KERNEL_MOD_DIR "$option";;
>> +        --kernel-src-dir=*) write_make_var KERNEL_SRC_DIR "$option";;
>> +        --kernel-obj-dir=*) write_make_var KERNEL_OBJ_DIR "$option";;
>> +        HAVE_ELF_GETSHDRSTRNDX=*) write_config_var HAVE_ELF_GETSHDRSTRNDX "$option";;
>> +        HAVE_LIBCTF=*) write_config_var HAVE_LIBCTF "$option";;
>> +        HAVE_STRRSTR=*) write_config_var HAVE_STRRSTR "$option";;
>> +        HAVE_LIBSYSTEMD=*) write_config_var HAVE_LIBSYSTEMD "$option";;
>> +        HAVE_FUSE_LOG=*) write_config_var HAVE_FUSE_LOG "$option";;
>> +        HAVE_LIBFUSE3=*) write_config_var HAVE_LIBFUSE3 "$option";;
>> +        HAVE_FUSE_NUMA=*) write_config_var HAVE_FUSE_NUMA "$option";;
>> +        HAVE_CLOSE_RANGE=*) write_config_var HAVE_CLOSE_RANGE "$option";;
>> +        HAVE_GETTID=*) write_config_var HAVE_GETTID "$option";;
>
> Have you considered introducing options for these list --with-* and --without-*,
> especially for things like libctf, libsystemd, and fuse?  The others relate to
> functions that we have our own implementation for if the libraries do not 
> provide one (or we cannot verify they do), so perhaps something lihe
> --with-own-* or --without-own-* could apply?

I never thought of that distinction. Good point: adjusted.

> That seems to be more configure-like and more consistent?  Or allow both?

I think allowing both is even more consistently, uh, consistent: you can
use HAVE_, echoing the config vars, if you like, or a --with/--without
if you like.