ports/build-tools/gmake/add.sh

set -e
 
git clone git://git.savannah.gnu.org/make.git
cd make
./bootstrap --skip-po
# every fixup flag below has to be given to ./configure, not just to the
# later ./build.sh invocation: build.sh's very first act (". ./build.cfg")
# sources a file *generated by configure* that assigns CFLAGS/CPPFLAGS
# itself, unconditionally overwriting whatever the ./build.sh command
# line set - only what configure itself was given ends up captured there.
#
# CPPFLAGS explicitly, not just CFLAGS: autoconf's own AC_PROG_CPP sanity
# check compiles its probe with $CC -E $CPPFLAGS, never $CFLAGS - a gcc
# built without --with-native-system-header-dir (see compilers/gcc/
# add.sh's own comment) has no default idea where the sysroot's real
# libc headers live, so a bare "gcc -E" fails to find <limits.h> at all
# without an explicit -I here. redundant once every installed gcc
# already has that configure flag baked in, harmless either way.
#
# gl_cv_func_fnmatch_gnu=yes: pre-seeds gnulib's own AC_CACHE_CHECK for a
# "working GNU fnmatch" (a standard, well-established autoconf technique -
# a cache variable already set in the environment short-circuits the
# check entirely) so it trusts musl's real, adequate fnmatch() instead of
# falling back to gnulib's own ancient fnmatch.c compat shim, which fails
# to even compile here: it redeclares getenv() the old K&R "unspecified
# args" way ("extern char *getenv ();"), which a real prototype
# (musl's stdlib.h) now conflicts with outright - a real ISO C rule this
# gcc enforces strictly, not something a CFLAGS warning flag can suppress.
#
# -Dgetenv=getenv: gnulib's fnmatch.c still gets compiled regardless of
# gl_cv_func_fnmatch_gnu (that only controls whether callers are
# REDIRECTED to it via fnmatch.h, not whether the .c file itself is part
# of the build) and guards its own stale "extern char *getenv ();" K&R
# redeclaration with "#if !defined _LIBC && !defined getenv" - a check
# from an era when a system might not declare getenv() in any header at
# all. defining getenv as a (harmless, self-referential) macro makes
# that guard false without touching the file, so the real prototype in
# musl's own stdlib.h is the only one gcc ever sees.
#
# gmake's own bundled src/getopt.c/getopt.h (an old, gnulib-style getopt
# compat implementation, same vintage and same class of issue as
# build-tools/gnu-binutils's libiberty/getopt1.c) has two more of these:
# getopt.h's own prototype is guarded by "#ifdef __GNU_LIBRARY__" (glibc-
# specific) - anything else falls through to a bare, unprototyped
# "extern int getopt ();", which then conflicts outright with getopt.c's
# own real, correctly-prototyped definition later in the same file.
# defining __GNU_LIBRARY__ is a well-established portable-getopt trick
# for exactly this: it selects the branch with a real prototype matching
# the standard POSIX getopt() signature, which musl (like glibc) actually
# implements - not a lie, just picking the branch that was only ever
# gated on "which library are we" instead of "does a prototype exist".
# separately, getopt.c calls getenv() without including <stdlib.h> in
# this branch at all: -Wno-implicit-function-declaration would silence
# that, but wouldn't fix it - an implicit, assumed-int-returning
# declaration would silently truncate the real pointer getenv() returns
# on a 64-bit target, not just annoy the compiler. force-including
# stdlib.h (same "-include" technique already used for vcs/git's own
# regex.h ordering fix) makes the real prototype visible instead.
#
# --disable-dependency-tracking: automake's depfiles bootstrap (config.status's
# own "executing depfiles commands" step) needs a real GNU make to set up
# its per-file .deps/*.Po tracking, which is exactly what's still missing
# at this point (that's the whole reason this port exists) - irrelevant
# for a ports build anyway, which always does one fresh clone+build, never
# an incremental rebuild dependency tracking would speed up.
# ${MP_PREFIX_BASE:-$MP_PREFIX}, not a bare $MP_PREFIX: runsh's own
# auto-appended -I<prefix>/include only lands in CFLAGS/LDFLAGS, never
# CPPFLAGS (see runsh.c), so this line adds it by hand and never
# benefited from mplib::resolve's own INPLACE_BASE fix. an ephemeral
# "mp reinstall --inplace" build's own $MP_PREFIX is a fresh, empty
# scratch prefix on purpose -- the live root's real headers are at
# MP_PREFIX_BASE instead in that case; a normal (non-inplace,
# non-slotted) build never sets it, so the fallback is unchanged.
# ac_cv_func_{strtoll,mkstemp,mktemp,realpath,atexit}=yes: autoconf's own
# AC_CHECK_FUNC probe for each of these declares it the old K&R
# "unspecified args" way ("char strtoll (void);" etc.) to check mere
# existence at link time, without including any real header - once this
# port's own -I actually exposes musl's real headers (see gm_base
# below), something transitively pulls in the REAL prototype (e.g.
# "long long strtoll(const char*, char**, int);"), and gcc correctly
# rejects the mismatch as a hard "conflicting types" error, not a
# warning. autoconf treats any nonzero exit from the probe as "function
# doesn't exist", so all five get wrongly cached as missing even though
# musl genuinely provides all of them - gnulib then compiles its own
# replacement for each, which for strtoll actually LINKS (unlike the
# other four, which just wasted a compile) and collides with musl's own
# real strtoll in libc.a: "multiple definition of `strtoll'". confirmed
# via this port's own ephemeral --inplace build's config.log. NOT the
# same fix for getloadavg (also a "conflicting types" hard error, also
# cached "no") - musl genuinely doesn't implement getloadavg at all, so
# "no" there is coincidentally the correct answer already.
gm_base="${MP_PREFIX_BASE:-$MP_PREFIX}"
gl_cv_func_fnmatch_gnu=yes \
ac_cv_func_strtoll=yes \
ac_cv_func_mkstemp=yes \
ac_cv_func_mktemp=yes \
ac_cv_func_realpath=yes \
ac_cv_func_atexit=yes \
CPPFLAGS="-I$gm_base/include -Dgetenv=getenv" \
CFLAGS="$CFLAGS -D__GNU_LIBRARY__ -include stdlib.h" \
	./configure --prefix=$MP_PREFIX --disable-dependency-tracking
# on a from-scratch mp-built system, gmake is often the first REAL make
# available at all - self-hosting the build from whatever %make-tag
# provider is already on PATH would be circular (and, if that happens to
# be pdpmake, impossible: gmake's own configure-generated Makefile uses
# target-specific variable assignment, a GNU make extension pdpmake
# doesn't implement, the exact incompatibility that motivated depending
# on a real gmake in the first place - see libcs/musl's own add.sh
# comment for the fuller story). build.sh is upstream's own answer to
# this: "build GNU Make in the absence of any 'make' program", a plain
# shell script that compiles everything directly - it needs no fixup
# flags of its own since it just sources build.cfg (see above).
./build.sh
install -m 755 make $MP_PREFIX/bin/gmake
# gmake owns the literal "make" command (pkg_conflicts guards this
# against bmake/pdpmake also wanting it): -jN parallel builds are a GNU
# extension neither bmake nor pdpmake implements, and the overwhelming
# majority of add.sh scripts in this tree call bare "make -j$MP_JOBS"
# without a second thought - anything that specifically needs a
# DIFFERENT make can still call it by its own real name (bmake, pdpmake),
# same as libcs/musl and coreutils/busybox already call gmake by name
# for their own, different reason (needing gmake even where gmake itself
# can't yet be bin/make - see musl's own add.sh comment).
ln -sf gmake $MP_PREFIX/bin/make