| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
has enough problems of its own.
|
|
Thank you, T. M. Pederson. This is PR #31081.
|
|
|
|
|
|
look into a private variable _PKG_CONFIG_LIBDIR. This variable should
*NOT* be settable by the user.
|
|
file's sole purpose was to provide a dependency on pkg-config and set
some environment variables. Instead, turn pkg-config into a "tool"
in the tools framework, where the pkg-config wrapper automatically
adds PKG_CONFIG_LIBDIR to the environment before invoking the real
pkg-config.
For all package Makefiles that included pkg-config/buildlink3.mk, remove
that inclusion and replace it with USE_TOOLS+=pkg-config.
|
|
|
|
|
|
reported by Lars Nordlund via tech-pkg@.
|
|
for many "core" modules, UTF-8 and Unicode bugfixes, and ithreads
bugfixes.
The major changes are in the pkgsrc infrastructure to handle Perl and
Perl modules. All pkgsrc-installed Perl modules are now installed in
"vendor" directories, and the perl interpreter has been modifed to
search for libraries in the following order: site, vendor, perl. The
Perl library is stored in a directory that is named for the Perl ABI
version associated with the Perl release, so any updates of Perl to
newer versions can be done "in-place" as long as Perl ABI version
remains the same. All Perl scripts and man pages are stored in
locations that won't conflict between site, vendor, and perl modules,
and a new utility perllink(1) now manages symlinks to those scripts
and man pages under the usual ${LOCALBASE}/bin and ${LOCALBASE}/man/man1.
PERL5_SITEPREFIX may be set to the prefix where local, site-specific
modules will be installed, e.g. PERL5_SITEPREFIX=/usr/local. Note
that modules installed here are completely unmanaged by pkgsrc.
Update the buildlink and tool dependencies on perl to require perl>=5.8.7
to reflect the new locations for Perl modules and the Perl shared
library.
|
|
dependency on groff just for tbl(1) when available in the base system.
also, add .if exists() around nroff(1) because SUNWdoc is optional.
|
|
it is correctly defined in tools.Darwin.mk and tools.Linux.mk.
|
|
Based on suggestion by Matthias Drochner.
|
|
is pkgsrc-supplied. In other cases, e.g. using the system tool,
falling back toS the system tool, etc., we should still create wrappers
and set "TOOL" variables.
|
|
value passed via the shell environment to the GNU configure script for
each of the "GNU" variables names for the tool. It defaults to the full
path to the real tool so that these may be safely embedded in scripts
and config files.
One exception is the value for YACC when we use bison. In that case,
pass YACC="bison -y" to the configure script so that we will invoke
bison in yacc-compatibility mode.
|
|
|
|
|
|
line (path and arguments) needed to run the real tool.
Modify TOOLS_<TOOL> to hold only the path to the real tool.
Modify falcons-eye/Makefile and qt3-libs/Makefile.common to use
TOOLS_CMDLINE_YACC instead of TOOLS_YACC to that they'll use "bison -y".
|
|
reflect the possible variable contents.
|
|
|
|
tool. This variable is defined if <TOOL> is defined for that tool (see
tools/defaults.mk) and TOOLS_PATH.<tool> is set.
|
|
TOOLS_REAL_CMD.<tool> => TOOLS_PATH.<tool>
TOOLS_REAL_ARGS.<tool> => TOOLS_ARGS.<tool>
TOOLS_REAL_CMDLINE.<tool> => TOOLS_CMDLINE.<tool>
|
|
to another. This appears to fix whatever hidden bug a bit more
completely. "make show-var VARNAME=RM" in pkgsrc/x11/kdepim3 no longer
returns an empty value.
XXX I still have no idea why this "fixes" the problem. I can't seem to
XXX create a test case that exposes this problem.
|
|
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.
|
|
was empty.
XXX I have no idea why this fixes the problem.
|
|
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.
|
|
PKGSRC_USE_TOOLS go away. There is now only a single USE_TOOLS variable
that specifies all of the tools we need to build/run the package.
|
|
any IMAKE_TOOLS in that case as well.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
(e.g. graphics/netpbm) use native bash if available.
|
|
lang/perl5 to perl-5.8.6nb4. Modify packages that referred to
lang/perl58 to point to lang/perl5 instead.
|
|
|
|
|
|
|
|
OpenBSD release, so check for the right location.
|
|
in tools/defaults.mk where they can be more widely used.
|
|
the perl interpreter.
|
|
dependencies on archivers/bzip2 and textproc/groff when they are
available in the base system.
|
|
used by pkgtools/xpkgwedge.
|
|
are automatically undefined after the loop exits.
|
|
shell builtins, e.g. echo, false, test, true, since those tools don't
have a full path.
|
|
"env" tool.
|
|
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.
|
