-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Make autoconf accept uutils mkdir as race-free #8896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
… default Fixes uutils#8880. - Default --version header to '(uutils coreutils)'; allow override for autoconf via UUTILS_VERSION_BRAND - Keep autoconf compatibility by setting UUTILS_VERSION_BRAND='GNU coreutils' when needed - Normalize program name to basename so header starts with 'mkdir ...' - Relax docs CI to accept both GNU/uutils brand strings - Relax mkdir test to accept both brand tokens - No behavior changes; display only
…LS_VERSION_BRAND; fix macro regression
…tests Default to honest '(uutils coreutils)' branding. Emit '(GNU coreutils)' only for likely autoconf probes of 'mkdir --version' when env/dir hints are present (and linux-only /proc best-effort). Normalize to basename already in place. Adjust tests to simulate autoconf env for compatibility assertion. Clippy and fmt clean; full test suite passes locally.
Remove UUTILS_VERSION_BRAND runtime override path. Keep compile-time option_env! for packagers if needed. Tests updated to remove env override case; autoconf compatibility still validated via autoconf-like env hints. fmt/clippy/tests green.
The branding detection mechanism implemented to fix issue uutils#8880 is only needed for autoconf < 2.72. Modern distributions (Ubuntu 25.10+) ship with autoconf >= 2.72, which always uses mkdir -p regardless of branding, making this workaround potentially unnecessary. Added clear documentation: - TODO(uutils#8880) comment explaining when this code could be removed - Detailed function documentation for should_emit_gnu_brand() - Decision point for maintainers to consider removal if supporting only modern autoconf versions This allows future maintainers to easily identify and remove the workaround if the project decides not to support autoconf < 2.72.
Sorry but it is a way too complex change for a legacy compat. |
repro
Ubuntu 25.10 podman --connection podman-machine-default run --rm \
-v "$HOME/.cache/uutils-test/coreutils-linux:/usr/bin/mkdir:ro" \
docker.io/library/ubuntu:25.10 \
bash -c '
apt-get update -y >/dev/null 2>&1
DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
autoconf automake libtool m4 grep ca-certificates >/dev/null 2>&1
autoconf --version | head -n1
/usr/bin/mkdir --version | head -n1
cd /tmp && rm -rf test && mkdir -p test/build-aux
cd test
cp /usr/share/automake-*/install-sh build-aux/ 2>/dev/null
printf "AC_INIT([test],[0.1])\nAC_CONFIG_AUX_DIR([build-aux])\nAC_PROG_MKDIR_P\nAC_OUTPUT\n" > configure.ac
autoconf >/dev/null 2>&1
./configure 2>&1 | grep "checking for a"
grep "^MKDIR_P=" config.log
'
autoconf (GNU Autoconf) 2.72
mkdir (GNU coreutils) 0.2.2
checking for a race-free mkdir -p... /usr/bin/mkdir -p
MKDIR_P='/usr/bin/mkdir -p' |
CodSpeed Performance ReportMerging #8896 will degrade performances by 3.42%Comparing Summary
Benchmarks breakdown
Footnotes
|
GNU testsuite comparison:
|
fixes #8880
Old autoconf (< 2.72) only trusts “GNU coreutils” in mkdir --version and can fall back to install-sh. This adds a tiny runtime heuristic so mkdir reports “GNU coreutils” only when it looks like an autoconf-style version probe, and otherwise keeps the honest “uutils coreutils”.
What I changed
Why
This makes autoconf 2.69 pick MKDIR_P='mkdir -p' instead of falling back to install-sh, addressing #8880. Autoconf 2.72+ is unchanged (it already uses mkdir -p).
Scope
Quick check