ports/build-tools/gnu-bison/add.sh

set -e
 
git clone git://git.savannah.gnu.org/bison.git
cd bison
git submodule update --init
./bootstrap --skip-po
# USE=yacc_wrapper (off by default, see pkg_use): --disable-yacc skips
# building/installing bison's own "yacc" POSIX-compat wrapper
# (src/yacc) and its man page (doc/yacc.1) -- see configure.ac's own
# AC_ARG_ENABLE([yacc], ...), a real, upstream-supported switch, not a
# downstream hack. this tree's own default %yacc provider is build-
# tools/byacc (see its own pkg.conf), and the default here is OFF
# (wrapper not built) so gnu-bison never collides with byacc's own
# "yacc" the moment something needs gnu-bison DIRECTLY (sysutils/
# gnu-patch's own hard dependency, for the "bison" binary specifically
# -- confirmed for real: mp's CONFLICT_PRIORITY can only let the
# package currently installing WIN a colliding file outright, never
# "install everything except this one path", so avoiding the collision
# at the source beats fighting over ownership of it after the fact).
# a site with no byacc installed at all (or that genuinely wants
# gnu-bison's own wrapper as the live "yacc") opts back in with
# "gnu-bison: USE=yacc_wrapper".
YACC_FLAG=--disable-yacc
if [ -n "$USE_yacc_wrapper" ]; then
	YACC_FLAG=--enable-yacc
fi
./configure --prefix=$MP_PREFIX $YACC_FLAG
# gmake explicitly: -jN parallel builds are a GNU make extension, not
# POSIX make - pdpmake understands neither -j on its own command line
# nor a -jN inherited via MAKEFLAGS, failing outright ("don't know how
# to make -j10") the moment either is present, regardless of whether the
# rest of the Makefile itself would otherwise be pdpmake-compatible.
# unlike libcs/musl and coreutils/busybox (which are this tree's %libc/
# %coreutils providers and would hit a GLOBAL_DEPS cycle depending on
# gmake formally), gnu-bison isn't a foundational tag provider, so a
# plain pkg_deps="gmake" (see pkg.conf) is safe here.
gmake CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" -j$MP_JOBS
gmake install
gmake clean || true