command that can be embedded into packages. Calling a bare "ldconfig"
will still call the one in the tools directory, which always does the
right thing.
Also, some configure scripts use "ENV" to represent the path to the
"env" tool, which is probably bad since ENV has a special meaning to
/bin/sh. To workaround this, set ac_cv_path_ENV.
USE_TOOLS and any of "autoconf", "autoconf213", "automake" or
"automake14". Also, we don't need to call the auto* tools via
${ACLOCAL}, ${AUTOCONF}, etc., since the tools framework takes care
to symlink the correct tool to the correct name, so we can just use
aclocal, autoconf, etc.
-- the checks for grep and egrep are broken because when passed GREP
and EGREP in the environment, the script causes GREP and EGREP to be
set to empty strings, which causes GNU configure scripts to hang or
break. Pass the real paths to grep and egrep through using ac_cv_path_GREP
and ac_cv_path_EGREP as well to avoid the brokenness. This fixes the
build of textproc/gsed.
paths for the tools that the package uses through the shell environment.
We do this since these paths may be hardcoded into package scripts,
and if they're not pre-specified, then they'll be searched for in the
PATH, which would find the ones in ${TOOLS_DIR}.
The variable names that GNU configure scripts expect are named in
_TOOLS_VARNAME_GNU.* for the various tools.
${WRKSRC}. Just directly create the msgfmt wrapper in the proper
target. Also, note that the msgfmt handling should eventually migrate
to the tools framework so that build dependencies and binary paths are
correct.
Plan:
(1) Change USE_PERL5=build into USE_TOOLS+=perl.
(2) Change all other USE_PERL5 into including perl5/buildlink3.mk.
Possibly, for packages that don't actually build anything with perl,
but merely require it for the perl interpreter, we can instead do:
USE_TOOLS+= perl
TOOLS_DEPMETHOD.perl= DEPENDS
but this is more verbose than simply including the perl5/buildlink3.mk
file.
Move the PERL5_REQD computation into a lang/perl5/version.mk file,
and only do the USE_PERL5 logic in bsd.pkg.use.mk if we're not using
the new tools framework. This consolidates all of the perl-handling
into two places -- lang/perl5 and mk/tools/perl.mk.
which can take multiple values -- "pax" or "gtar". The default value
of EXTRACT_USING is "pax", which more closely matches reality since
before, we were using bootstrap "tar" for ${GTAR} and it was actually
pax-as-tar. Also, stop pretending pax-as-tar from the bootstrap kit
or on NetBSD is GNU tar. Lastly, in bsd.pkg.extract.mk, note whether
we need "pax" or "gtar" depending on what we need to extract the
distfiles.
"bison" and "bison-yacc". bison is just a symlink to the real bison,
but "bison-yacc" provides a "yacc" in ${TOOLS_DIR} that does "bison
-y". This allows the tools framework to provide everything that a
package might look for when asking for "bison" and avoids relying on
the bison being available in the PATH.
Ditto for mailx. Lastly, /usr/bsd/zcat isn't gzcat (doesn't understand
gzipped files), so don't use it as a gzcat replacement. Changes from
Georg Schwarz in private email.
as needing both (no impact since they're both satisfied by the tar
binary installed by the bootstrap kit). There's some funniness in
the extraction code where we check for pax or GNU tar that needs to
be resolved. Remove the TAR=${GTAR} hack since it's no longer needed
after these changes.
XXX Later, a sweep needs to be made to see where we actually need GTAR
XXX and where we only need TAR, probably triggered by whether we call it
XXX with the "z" option or not. Packages that need GTAR should explicitly
XXX add USE_TOOLS+=gtar to the package Makefile.
other files without making assumptions about the location of the top of
the pkgsrc tree. This fixes problems with running "make bulk-cache"
in /usr/pkgsrc (PR pkg/30288).
modify bsd.pkg.extract.mk to use them. As a side-effect, we stop
hardcoding ${LOCALBASE} as the install prefix for these tools so this
becomes more pkgviews-friendly.
in mk/tools/perl.mk since many packages expect to be able to use the
variables defined in vars.mk, but those variables can only be defined
if PERL5 is correctly defined, and that is only true after it is set
here.
VAR= a
PTR= VAR
${PTR}?= b
Given these definitions, ${VAR} == "b" (unintuitively). We can work
around this by doing:
VAR= a
PTR= VAR
.for _v_ in ${PTR}
${_v_}?= b
.endfor
In this case, ${VAR} == "a" (as expected).
Use the second form of assignment in this changeset so that the expected
behavior happens for the "TOOL" name variables. This fixes "recursively
defined" errors for some of the "TOOL" variables when the pkgsrc tool
replaces the system-supplied one.
within make. This allows us to use EVAL_PREFIX to locate the installation
prefix for autoconf and automake, which is more pkgviews-friendly. In any
case, this implementation is a lot simpler anyway.
${TOOLS_DIR} so that we avoid inspecting various variables during the
top-level make invocation -- rather, we defer inspection until the
target is actually made. This allows TOOLS_REAL_CMDLINE.*,
TOOLS_REAL_CMD.*, and TOOLS_REAL_ARGS.* to be defined after bsd.tools.mk
is included and still affect the creation of the tools under ${TOOLS_DIR}.
value of TOOLS_REAL_CMDLINE.makeinfo. In this case, we split MAKEINFO
into the command and the arguments, and allow the default command line
to be constructed.
This makes more sense since there is never going to be a pkgsrc
replacement for ldconfig. We now always create an ldconfig tool in
${TOOLS_DIR} that either calls the system-supplied one if it exists,
or is a no-op.
that a package needs. Tools that pkgsrc needs are listed in
PKGSRC_USE_TOOLS, and tools that a package needs on top of that are
listed in USE_TOOLS.
Define "TOOL" variables, e.g. SED, AWK, MKDIR, etc. for each of the
tools that pkgsrc needs, and "TOOLS_TOOL" variables, e.g. TOOLS_SED,
TOOLS_AWK, TOOLS_MKDIR, etc. for each of the tools that a package
needs. These variables contain the full command line to the real
command and arguments needed to invoke the tool.
created under ${TOOLS_DIR} that invoke <tool>, e.g.
TOOLS_ALIASES.gawk= awk
The example above causes the "gawk" tool to be added to ${TOOLS_DIR} as
both "gawk" and "awk".
framework figure out by itself whether a wrapper or a symlink should be
created based on the real command and any arguments that may need to be
invoked.
packages to strip installed executables. If INSTALL_UNSTRIPPED ==
"yes", then we create a "strip" wrapper in ${TOOLS_DIR} that just
calls ${TRUE} by considering ${TRUE} the system-supplied strip command.
default value for each platform. Currently, the replacement tools
comes from sysutils/coreutils, but where there is no native BSD install
program, bootstrap-pkgsrc should probably be made to provide an install
shell script as an alternative, and mk/tools/bootstrap.mk should be
amended accordingly.
Also remove one use of ${TYPE} in pkgsrc (bsd.pkg.mk) under the new tools
framework.
* Get rid of an explicit check for ${_IMAKE_MAKE} == ${GMAKE} in
bsd.pkg.mk to check for whether we need to depend on gmake or not.
Instead, we now note in Linux.mk that packages that need imake will
also need to use gmake by setting _IMAKE_TOOLS+=gmake.
* Push the definition of MAKE_PROGRAM from bsd.pkg.mk into make.mk where
it's closer to related code.
the "TOOL" variables won't be properly defined for the top-leve make
after returning from making the install-depends target if we're using
the pkgsrc-supplied tool. Define the "TOOL" variable unconditionally
instead.
to provide "TOOL" definitions for tools used by a top-level make process
(usually because it uses them in a != variable definition). This allows
USE_TOOLS to be defined before bsd.prefs.mk is included by a package
Makefile, where USE_TOOLS lists the additional (non-default) tools that
are required to build the package.
Also, drop the fallback to existing "TOOL" definitions because we now
have TOOLS_PLATFORM.* for each platform in pkgsr/mk/tools/tools.*.mk.
tools that are overridden by superseding ones. Use it in place of
USE_TOOLS in most places. This fixes the situation where we can
depend on the tool that overridden, e.g. USE_TOOLS= gawk awk.
Where bootstrap installs these tools, they should be considered system-
supplied since pkgsrc won't be providing replacements for them.
bootstrap.mk encapulates the information from the bootstrap script. It
should eventually go away after the bootstrap script has been taught to
write out the correct TOOLS_PLATFORM.* entries to the example mk.conf
file.
also create either a wrapper or a symlink depending on whether it has
any arguments or not. While we're here, correct the comment block to
include a description of PLATFORM_TOOL.*.
tools that are defined as a command plus arguments, e.g. for gunzip,
GUNZIP= /usr/bin/gzip -d
In this case, we generate a wrapper script that invokes the real
command plus arguments. If there are no arguments, then just symlink
the command for simplicity.
Also, restructure the tool-specific blocks so that we always define
TOOLS_CMD.<tool> to the correct name (important for yacc/bison), and
check that the real command actually exists before assigning it to
the "TOOL" name.
behavior is deemed too undeterministic and too complex for bsd.tools.mk,
which should just be providing simple building blocks for creating
simple wrappers and symlinks. These searches are better implemented
elsewhere.
to be a drop-in replacement for mk/tools.mk, but isn't yet enabled
pending further testing. To use, edit bsd.pkg.mk to include bsd.tools.mk
instead of tools.mk.
The major changes from the old tools framework are:
(1) The new interface to using the tools framework is through setting
USE_TOOLS in the package Makefile, e.g.,
USE_TOOLS+= autoconf gmake yacc
(2) Bison/yacc handling is improved. Instead of adding checks for
/usr/bin/yacc to the package Makefile and explicitly setting YACC,
e.g., security/mit-krb5/Makefile, simply add "yacc" to USE_TOOLS.
If bison is explicitly required, then add "bison" to USE_TOOLS
instead.
(3) GNU auto* tools are handled differently. "autoconf", "aclocal",
"automake", etc. will be tools in ${TOOLS_DIR} that point to the
correct versions of the auto* tools. Instead of patching Makefiles
or scripts to use ${AUTOCONF}, ${ACLOCAL}, etc., the correct
versions of the tools will be called if they are invoked simply
by their bare names. This is selected by adding either "autoconf"
or "autoconf213", or "automake" or "automake14" to USE_TOOLS.
The new tools framework will deprecate the following variables:
ACLOCAL AUTORECONF
AUTOCONF BUILD_USES_GETTEXT_M4
AUTOHEADER USE_GNU_TOOLS
AUTOMAKE USE_TBL
The new tools framework will deprecate the following *.mk files:
mk/autoconf.mk
mk/automake.mk
mk/tools.mk
Additional documentation on how to use bsd.tools.mk to create new tools
under ${TOOLS_DIR} may be found in the header comments in bsd.tools.mk.
