These no longer support being executed via a symlink, failing with errors
such as:
xcode-select: Failed to locate 'gmake', and no install could be requested
This breaks the entire .tools/bin directory, so we just have to avoid them
and use tools from pkgsrc instead.
It's likely a lot more will need to be added to this list, but this is
enough to get devel/cmake building at least.
This case can only happen in the following special case:
TOOLS_CREATE+= asdf
TOOLS_PATH.asdf= # empty
If there is a lonely TOOLS_CREATE without a corresponding TOOLS_PATH, it
defaults to ${FALSE} and thus doesn't trigger this code.
Packages that don't declare USE_TOOLS+=perl and whose configure script
invokes perl produce a warning.
Usually warnings are ignored, but they can also be configured as errors,
for example during a strict bulk build. In this situation it is
necessary to override the default behavior of the perl tool to fail
silently. Up to now, defining both TOOLS_BROKEN+=perl and
TOOLS_FAIL+=perl produced a duplicate make target.
To handle this situation, let TOOLS_BROKEN+=perl take precedence over
TOOLS_FAIL+=perl. This is much easier than finding out in each case how
to disable the perl check in the configure script, which is most often
done by adding any of the following to CONFIGURE_ENV: PERL=#none,
ac_cv_prog_PERL=#none, ac_cv_path_PERL=#none.
This information is useful for getting the variable name that corresponds
to a tool. In most cases this is just the uppercase name of the tool,
but there are exceptions like ${SETENV} for env, ${HOSTNAME_CMD} for
hostname.
Previously a "grep" tool was created, but GREP still pointed at the platform
grep, breaking any package that used the environment variables rather than
PATH when the native platform grep does not have GNU features.
When "bmake clean depends" was called for a package where the various
cookie files already existed, these would enable different rules than a
clean package directory.
Since "bmake clean" deletes all the cookie files before "bmake depends"
starts, in these combined command lines the cookie files must be treated
as absent.
If a package had said FLEX_REQD=1000.0, the actual dependency had still
been flex>=2.5.4. Now all version numbers from FLEX_REQD are taken into
account, too.
Before, the tool arguments were written to the log as plain strings. Now
the arguments are properly quoted, which makes it possible to replay the
commands by copying them from the .work.log file.
This only affects tools that are shell builtins (echo, true, false), get
additional arguments (mkdir -p) or define a custom TOOLS_SCRIPT
(pkg-config, to set an environment variable; or autotools). Tools that
are symlinked to the real tool are not affected.
The calls to the compiler are already properly logged since cwrappers
takes care of that. This commit therefore makes the log entries for the
compilers and the other tools more similar.
When a package or the infrastructure defined a tool with custom
TOOLS_ARGS or TOOLS_SCRIPT containing special characters, these could
lead to unintuitive interactions at the time when that tool invocation
was logged in the tool wrapper log. Some of the logging output ended up
on stdout, while some of the normal output ended up in the log, and parts
of the quoted arguments were even evaluated as shell commands.
The logging of the wrapped tool commands is not perfect yet, but at least
it's much more predictable now.
The check to avoid possible dependency loop was not updated to
check devel/nbpatch (instead of devel/patch).
Fix PR pkg/53920 reported by Dean Matzkov.
Up to now, there was a central list of variable name patterns that
defined whether a variable was printed as a sorted list, as a list or as
a single value.
Now each variable group decides on its own which of the variables are
printed in which way, using the usual glob patterns. This is more
flexible since different files sometimes differ in their naming
conventions.
Two variable groups are added: license (for everything related to
LICENSE) and go (for lang/go).
Platform support is determined by _OPSYS_SUPPORTS_CTF from mk/platform, the
user enables support by setting PKGSRC_USE_CTF=yes, and packages can
explicitly disable support with CTF_SUPPORTED=no or skip certain files with
CTF_FILES_SKIP.
The path to ctfconvert is configured via TOOLS_PLATFORM.ctfconvert.
If all of the requisite variables are enabled, a compiler-specific debug flag
is passed via the wrappers to ensure we have DWARF information to convert,
_INSTALL_UNSTRIPPED is explicitly defined to avoid binaries being stripped
prior to conversion, and the conversion is performed during the install stage.
It is recommended that users who enable the feature also set STRIP_DEBUG=yes
to reduce the final binary size once the conversion has been performed.
This has been used for the past year in Joyent SmartOS builds. FreeBSD is
marked as supported but is untested.
This is for when GNU features are required that aren't available in some
other greps, for example -o or --color. If ggrep is requested then it
takes precedence over grep/egrep/fgrep and the GNU versions are used for
all three.
BSD grep aims for GNU compatibility so it is anticipated that it can be
used as a native tool to avoid a dependency on textproc/grep on platforms
that provide it.
This is based on the decision The NetBSD Foundation made in 2008 to
do so, which was already applied to src.
This change has been applied to code which is likely not in other
repositories.
ok board@, reviewed by riastradh@
The "split" program is not managed by the tools framework. It just has a
wrapper that is placed into the same directory. This is confusing since
intuitively, "split" is a tool like many others.
The "duplicate script for target" warning from Make is therefore correct,
albeit obscure.
Currently, neither the pkgsrc infrastructure nor pkglint check for
allowed tool names.
The TOOLS_CREATE variable is only ever appended to, without checking for
duplicates. In some rare cases, this produces warnings about
doubly-defined make targets. An example is adding USE_TOOLS+=strip to
pkgtools/pkglint:
".../mk/tools/create.mk" line 149: warning:
duplicate script for target ".../work/.tools/bin/strip" ignored
The above line number 149 is zero-based, which in reality means the
duplicate definition is in line 150.
