the GNU auto* tools from being executed during the build process. We now
just create shell scripts that simply return an error status for each of
the GNU auto* tools in ${BUILDLINK_DIR}/bin and ignore the other goop in
bsd.pkg.mk that tried to accomplish the same thing.
shells to /etc/shells.
This feature can be disabled by setting PKG_REGISTER_SHELLS to NO in
/etc/mk.conf.
An excerpt from Packages.txt, section 10.28:
10.28 Packages providing login shells
=====================================
If the purpose of the package is to provide a login shell, the variable
PKG_SHELL should contain the full pathname of the shell executable installed
by this package. The package Makefile also must include
"../../mk/bsd.pkg.install.mk" prior to the inclusion of bsd.pkg.mk to use the
automatically generated INSTALL/DEINSTALL scripts.
An example taken from shells/zsh:
PKG_SHELL= ${PREFIX}/bin/zsh
.include "../../mk/bsd.pkg.install.mk"
The shell is registered into /etc/shells file automatically in the
post-install target by the INSTALL script generated by bsd.pkg.install.mk and
removed in the deinstall target by the DEINSTALL script.
back to the current page, just list it as regular text.
- Put each dependency hyperlink on a separate line in the README.html file.
These were both noted by Thomas Klausner in a private email.
avoid simply appending to it.
- add some additional error checks when using the -r/--restart options to
make sure that the database exists and give a useful error message if it
doesn't
directory of a single package (e.g. graphics/gimp) for which a README.html
is to be generated. This provides the required hook to be able to use this
script to generate a README.html file for a single package as well as
for all packages.
don't exist, exit with a fatal error and don't try and make empty README.html
files.
- fix a bug which caused some duplication in category README.html files.
Problem noted on netbsd-help@ by Nicolas Saurbier ( Nicolas dot Saurbier at biodata dot de)
way than the previous recursive make approach. The 'mkreadme' script is
the top level script. 'mkreadme -h' or 'mkreadme --help' for complete
documentation on its use. Generates README.html files more than two orders
of magnitude faster than the recursive make approach by only calling make(1)
once per pkg.
It runs pre-test, do-test, and post-test. The default pre-test and
post-test targets are empty; the default do-test target runs
TEST_TARGET (in each TEST_DIRS (defaults to BUILD_DIRS)) if it is set
and does nothing otherwise. Thus the test target defaults to doing
nothing.
The usual way to use this is to set TEST_TARGET to the target to run
(e.g. TEST_TARGET=check for GNU packages).
If PKGSRC_RUN_TEST is set to yes (in mk.conf, defaults to no),
the test target is run before install.
(approved by agc)
causes the shell environment to be discarded. This also discards
OBJMACHINE or OBJHOSTNAME, which causes WRKDIR_BASENAME to be different
between the "non-root" and "root" make targets and leads to the breakage
seen in pkg/18879 by Simon Burge. Fix this by saving the OBJHOSTNAME or
OBJMACHINE setting in MAKEFLAGS so that it is seen even after we "su -l" to
root.
if the package uses X11 and merge the BUILDLINK_X11PKG_DIR and
BUILDLINK_X11_DIR variables into a single variable: BUILDLINK_X11_DIR.
This creates a one-to-one mapping between X11BASE and BUILDLINK_X11_DIR,
instead of X11BASE mapping to both BUILDLINK_X11_DIR and to
BUILDLINK_X11PKG_DIR.
Remove the now unused II and LL parts of the BUILDLINK_TRANSFORM language.
Add a new "static" keyword to the mini-language and fix building
statically-linked binaries when building with libtool.
.transform.sed and .untransform.sed that are generated by a new
gen-transform.sh shell script. This avoids all of the silliness with
exceeding the length of the value of a make variable that brought about
breaking the original _BLNK_TRANSFORM_SED into _BLNK_TRANSFORM_SED.[1-4].
It's also vastly easier to understand the gen-transform.sh script as
opposed to the juxtaposition of make and sed regular expressions, a.k.a.
massive eyesores, that were in bsd.buildlink.mk.
Also fix the directory protection scheme so that it might actually work
if the pkgsrc directory is a subdirectory of /usr/pkg (${LOCALBASE}).
Lastly, filter out /usr/X11R6 (${X11BASE}) if the package doesn't define
USE_X11. This should catch packages that use X11 without announcing it,
and avoids one way you can circumvent buildlink2.
Compare...
$ gmake --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386--netbsdelf
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Report bugs to <bug-make@gnu.org>.
to...
$ gmake --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
# Used in the rpm package to note the prefix of the path to the RPM
# databases. The RPM databases are stored in ${RPM_DB_PREFIX}/lib/rpm.
# Possible: any valid location, e.g. ${LOCALBASE}
# Default: /var/pkg
dependencies to deal with changes in the source rc.d script file (this is
possible now that some variables have moved to bsd.prefs.mk from
bsd.pkg.mk).
2. New variable PKGNAME_PREFIX, which is either null string or xemacs-
depending on EMACS_FLAVOR. Intended to use like:
DEPENDS+= ${PKGNAME_PREFIX}apel>=10.4:../../devel/apel
BUILD_DEPENDS+= ${PKGNAME_PREFIX}apel>=10.4:../../devel/apel
JVMs from the package-provided PKG_JVM_ACCEPTED list, filter out those
JVMs that aren't available for the current platform. This allows a
package to simply list all JVMs that may be used to build it in
PKG_JVM_ACCEPTED, regardless of platform issues, instead of having to
construct a different PKG_JVM_ACCEPTED based on the platform we are using.
platform, and use the intersection of these JVMs and the ones
listed in PKG_JVMS_ACCEPTED as the JVMS that may really be used.
Currently, we assume all of the JVMs are usable by all platforms.
in bsd.pkg.mk. The java.mk Java handling is largely based on the
lang/python/pyversion.mk file.
There are two new variables:
PKG_JVM_DEFAULT is a user-settable variable whose value is the
default JVM to use.
PKG_JVMS_ACCEPTED is a package-settable list of JVMs that may be
used as possible dependencies for the package.
Two existing variables have been redefined to be only read-only, though
there is some logic to handle legacy /etc/mk.conf which may contain an
explicit PKG_JVM=...
PKG_JVM is a publicly readable variable containing the name of
the JVM we will be using.
PKG_JAVA_HOME is a publicly readable variable containing
${JAVA_HOME} for the PKG_JVM described above.
To do:
Have some way to specify which JVMs are acceptable for each
platform, and use the intersection of these JVMs and the ones
listed in PKG_JVMS_ACCEPTED as the JVMS that may really be used.
Currently, we assume all of the JVMs are usable by all platforms.
I'm not sure if Darwin's special stub sun-{jre,jdk}13 packages
are usable by buildlink2. This needs to be verified.
stdout a list of files relative to ${BUILDLINK_PREFIX.<pkg>}. The shell
variable $${pkg_prefix} may be used and is the subdirectory (ending in /)
of ${BUILDLINK_PREFIX.<pkg>} to which the PLIST is relative, e.g. if
`pkg_info -qp foo' returns "/usr/pkg/java/kaffe", then $${pkg_prefix} is
"java/kaffe/".
BUILDLINK_PKGBASE.<pkg> that is the ${PKGBASE} for that package and can
be used as "pkg_info ${BUILDLINK_PKGBASE.<pkg>}". This variable is
currently only used if the buildlink2.mk file uses
BUILDILNK_PLIST_CMD.<pkg> (described below).
* Create readable variable BUILDLINK_PLIST_CMD.<pkg> that is a pipeline of
shell commands that outputs to stdout a list of the files installed the
<pkg>, relative to its installation prefix.
readable through CONFIGURE_ENV and MAKE_ENV. These may be used to fix
up packages that use imake to check the appropriate locations for headers
and libraries.
* Don't be so aggressive in prepending _BLNK_{CPP,LD}FLAGS to
{C,CPP,CXX,LD}FLAGS. The buildlink2 wrapper scripts will automatically
filter out bad -[IL] paths, even if their added inadvertantly by package
Makefiles, so we can simply append them to the existing
{C,CPP,CXX,LD}FLAGS. We try to be smarter about appending them to avoid
needless duplication.
${CONFIGURE_ENV} and in ${MAKE_ENV} for the configure and build processes,
respectively. This allows overriding the value of "CC" passed to the
build, e.g.:
BUILDLINK_ENV+= CC="/usr/pkg/pthread/bin/pgcc"
Disables to "no", which results in no gnome-libs being needed.
Patch contributed by Stefan Krüger <skrueger@europe.com> in private mail,
with some changes from me.
SPECIAL_PERMS are lists that look like:
file user group mode
At post-install time, file (it may be a directory) is changed to be
owned by user:group with mode permissions.
SPECIAL_PERMS should be used primarily to change permissions of files or
directories listed in the PLIST. This may be used to make certain files
set-uid or to change the ownership or a directory.
Packages that install setuid executables should list them in SPECIAL_PERMS
so that the correct user and group will be used for file ownership, even
if the uid/gid changes between the package creation and the package
installation.
was only able to check the paths for NetBSD and Linux...Solaris and Darwin
pkgsrc developers should change the path to expr in the right defs.*.mk
file.
environment. Instead, create a new variable PKG_JAVA_HOME, which is
passed to the configure and build processes via:
JAVA_HOME=${PKG_JAVA_HOME}
to override any environment setting for JAVA_HOME. This should fix
pkg/17989.
preference to or in place of Sun audio support in various packages. People
using audio/oss should set USE_OSS in their /etc/mk.conf when building
packages.
when support for BUILD_DEPEND-only java packages was introduced -- this problem
was preventing java from being registered as a dependency for a number of java-based
packages.
to only add -Ldir/.libs for *.la files that are not named with absolute
paths or named with an absolute path starting with ${WRKSRC}. This should
fix the problem with converting kdebase3 to buildlink2.
overflowing the make variable size limit.
* Rename _BLNK_WRAP_ENV to _BLNK_WRAP_SETENV, and use _BLNK_WRAP_ENV to
set the shell environment for the wrappee. Allow BUILDLINK_WRAPPER_ENV
to add to the shell environment.
a full dependency. BUILDLINK_DEPMETHOD.<pkg> is now a space-separated
list of the words "full" and/or "build", and if any of them is "full",
then a full dependency on <pkg> is used. buildlink2.mk files may now do:
BUILDLINK_DEPMETHOD.<pkg>+= full
to convert from a build to a full dependency.
Previously, if a package Makefile set BUILDLINK_DEPMETHOD.<pkg>=build,
there was no way to override its value consistently.
use buildlink2 and set USE_X11 will use x11-links, or if they will simply
symlink the X11 files directly into ${BUILDLINK_DIR}. If USE_X11_LINKS is
"YES" (the default), then x11-links is used. If USE_X11_LINKS is "NO",
then the X11 files are symlinked directly.
There is a choice here between speed and flexibility. Using x11-links is
faster since you don't need to spend time symlinking all of the X11 files
into ${BUILDLINK_DIR}. However, if you update your X11 installation, then
the x11-links package will likely be out-of-date. Conversely, directly
symlinking the X11 files will protect you from changes in your X11
installation when you update, but there is a (small) time penalty to have
to do it for every package that uses X11.
buildlinking them into ${BUILDLINK_DIR}. This should allow cases where a
/usr/lib/libintl.la escaped into an installed libtool archive (during the
time when buildlink2 was broken for about 4 days) to be handled properly.
BUILDLINK_DEPENDS.foo= foo>=1.0 foo<1.5
then this is converted to:
DEPENDS+= foo>=1.0:../../category/foo
DEPENDS+= foo<1.5:../../category/foo
We can use this to record upper bounds on dependency versions.
directory escape into the installed *.la files. Fix this by only adding
-L*/.libs if the *.la file is uninstalled, and by filtering out references
to ${WRKSRC}.
* Replace ELK_USE_{X11,MOTIF} with ELK_GUI, which is either "none" or is
some combination of "xaw" and/or "motif".
* Reenable Motif -- it seems to build properly with OpenMotif-2.0.x.
* Modernize this package a bit and clean up how linker flags are passed to
the build process by using the new variables available.
the main transformations have been performed.
The ld wrapper can now accept "-Wl,*" arguments and transform them
appropriately by stripping of the -Wl and the commas. This will obiviate
the need for logic in pkgsrc that strips away the "-Wl," depending on
whether the platform was a.out or ELF, and whether the individual package
chose to link using "cc" or "ld".
depend on other uninstalled libtool archives. During the relinking process
the newly installed libraries weren't being found. We now insert the
appropriate -Ldir flags to allow them to be found in the uninstalled
locations.
/etc/rc.d. This is controlled by the new variable PKG_RCD_SCRIPTS which
may be set in /etc/mk.conf or in the shell environment in which the
INSTALL script is executed. PKG_RCD_SCRIPTS only takes effect if
${PKG_CONFIG} == "YES" and defaults to NO.
RCD_SCRIPTS. From the comments in bsd.pkg.install.mk:
# rc.d scripts are automatically generated and installed into the rc.d
# scripts example directory at the post-install step. The following
# variables are relevent to this process:
#
# RCD_SCRIPTS lists the basenames of the rc.d scripts
#
# RCD_SCRIPT_SRC.<script> the source file for <script>; this will
# be run through FILES_SUBST to generate
# the rc.d script
#
# RCD_SCRIPTS_EXAMPLEDIR the directory in which to install the
# example rc.d scripts
#
# If the source rc.d script is not present, then the automatic handling
# doesn't occur.
bsd.buildlink2.mk. This allows packages that use buildlink2 to fix up
*-config and other shell scripts that hardcode wrong library names as a
side-effect of how buildlink2 works, e.g., the package thinks "-laa" works
because the wrapper silently converts it to "-laa-x11.
REPLACE_BUILDLINK files relative to ${WRKSRC}
REPLACE_BUIDLINK_PATTERNS shell glob
REPLACE_BUILDLINK_SED sed expression to run over the files named
above
buildlink2. We used to create a timestamp file in the .libs directory.
Now, we add a line to the *.la and *.lai file that directly notes that it
has been "modified by buildlink2". This makes it easier to debug problems
caused by using the wrong libtool during either a build or install by
checking if the *.la or *.lai files have the "modified by buildlink2" line.
the shell would definitely interpret in a wrong fashion (like
"perl>=5.0" - we don't want to create some file).
Pointed out by Jan Schaumann <jschauma@netmeister.org> on tech-pkg.
dependency on ghostscript. This handles the dependency patterns that will
match either ghostscript{,-nox11} and ghostscript-gnu{,-nox11} depending
on which version number of ghostscript is required. From the comments at
the top of the file:
To use this Makefile fragment, simply:
(1) Optionally set GHOSTSCRIPT_REQD to the minimum version number of
Ghostscript required by the package,
(2) Optionally set USE_GHOSTSCRIPT to "build" to only add a build-time
dependency on Ghostscript,
(3) And include this Makefile fragment in the package Makefile,
CONFIGURE_DIRS, and allows running the shell commands in the do-build and
do-install targets within the specified directories. Both variables
default to ${WRKSRC}.
${_PKGSRCDIR} and ${BUILDLINK_DIR} from any filtering, as they may be
subdirectories of ${LOCALBASE}, /usr/pkg, or /usr/local.
This should fix pkg/18142 and other puzzling problems reported on the
tech-pkg mailing list where it was necessary to revert back to buildlink1
versions of packages in order to build when the pkgsrc tree or the work
directories are kept under /usr/local.
contains all of the transformations that we may want to use to fix up
any *-config scripts that have incorrect paths or library names. Also
add some _BLNK_UNTRANSFORM_SED.* variables that do the opposite of the
corresponding _BLNK_TRANSFORM_SED.* variables, and that are used to clean
up libtool archives.
generalise the linker flags used to export symbols by setting them on
a per-OS basis.
> many packages force -Wl,-export-dynamic which is not portable outside GNU ld
> and cause problems e.g. on Solaris. some of these packages use if
> conditionals either only for NetBSD or except SunOS, but the state is not
> coherent and it may complicate later when support for new OS is added to
> pkgsrc (e.g. ongoing work on HP-UX support).
>
> jlam proposed the following framework in discussion on tech-pkg:
>
> http://mail-index.netbsd.org/tech-pkg/2002/06/21/0009.html
>
> now, ${EXPORT_SYMBOLS_LDFLAGS} is used instead of directly defining
> -Wl,-export-dynamic which is set in appropriate defs.*.mk to reasonable
> values. packages should be converted to this framework by:
>
> 1) replacing LDFLAGS+= -Wl,-export-dynamic and LIBS+= -export-dynamic with:
>
> LDFLAGS+= ${EXPORT_SYMBOLS_LDFLAGS}
>
> 2) for use in patchfiles, add this variable to MAKE_ENV if needed:
>
> MAKE_ENV+= EXPORT_SYMBOLS_LDFLAGS=${EXPORT_SYMBOLS_LDFLAGS}
>
> 3) replace occurances of -Wl,-export-dynamic and -export-dynamic in patch
> files with:
>
> $(EXPORT_SYMBOLS_LDFLAGS)
add one section for SunOS to possibly allow using the SUNWspro compilers
when building X11 packages that use imake. Many thanks to Matthias Scheler
for his help on this.
Also use _BLNK_OPSYS instead of OPSYS in bsd.buildlink2.mk so that's it's
easier to pretend I'm using a different OS when doing buildlink2 work.
This script is part of the buildlink2 infrastructure and is harmless if
not used. This allows devel/zlib to build on Solaris. Problem noted by
Stoned Elipot.
OPENSSH_USER
OPENSSH_UID
OPENSSH_GROUP
OPENSSH_GID
OPENSSH_CHROOT
Use these to automatically create user/group if they do not already
exist. Assists platforms which do not have an 'sshd' user by default,
while adding flexibility for NetBSD systems.
Checked by Stoned Elipot <seb@netbsd.org>.
Each word of UNLIMIT_RESOURCES is supposed to be a knob on
ULIMIT_CMD_<word> variable which value if defined is added to _ULIMIT_CMD.
The ULIMIT_CMD_* variables are set per $OPSYS in defs.*.mk and are overridable
by the user.
Solaris' default value of ULIMIT_CMD_memorysize adjusted as suggested in PR
pkg/18087 by Jonathan Perkin <sketch@rd.bbc.co.uk>.
