tools listed in USE_TOOLS -- some of them are required by the pkgsrc
infrastructure in variable assignment statements that look like:
VARIABLE!= ${AWK} ...
These tools are actually *required* by pkgsrc to be installed on the
system before it can even work (bootstrap situation). For these tools,
only override the "TOOL" name representing the tool if we're really
using the pkgsrc version of the tool.
We accomplish this by adding a new :pkgsrc modifier that is appended
to these tools listed in USE_TOOLS. We also list these tools in
bsd.prefs.mk so that all packages pick them up fairly early on.
around at either build-time or at run-time is:
USE_TOOLS+= perl # build-time
USE_TOOLS+= perl:run # run-time
Also remove some places where perl5/buildlink3.mk was being included
by a package Makefile, but all that the package wanted was the Perl
executable.
run-time dependency (DEPENDS) on a tool is to append a ":run" modifier
to the tool name, e.g.,
USE_TOOLS+= perl:run
Tools without modifiers or with an explicit ":build" modifier will
cause build dependencies (BUILD_DEPENDS) on those tools to be added.
This makes the notation a bit more compact.
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.
