Syntax:
MASTER_SITES_completefilename= http://specific.master/site
and similarly for PATCH_SITES.
Convert print/ghostscript-nox11 and x11/kterm to take advantage of this.
currently only occurs for packages that use bsd.pkg.install.mk.
There are two new targets, pre-install-script and post-install-script, that
default to doing nothing. The order of targets called for a "make install"
is:
pre-install-script
pre-install
do-install
post-install
post-install-script
The new targets are defined in bsd.pkg.install.mk to call the INSTALL
script with the PRE-INSTALL and POST-INSTALL options.
LIBTOOL_OVERRIDE steps into a separate do-libtool-override target. Create
a new variable _CONFIGURE_POSTREQ that currently lists do-libtool-override.
Also add some documentation for the two _CONFIGURE_* variables:
_CONFIGURE_PREREQ is a list of targets to run after pre-configure but before
do-configure. These targets typically edit the files used by the
do-configure target.
_CONFIGURE_POSTREQ is a list of targets to run after do-configure but before
post-configure. These targets typically edit the files generated by
the do-configure target that are used during the build phase.
pkgsrc. Instead, a new variable PKGREVISION is invented that can get
bumped independent of DISTNAME and PKGNAME.
Example #1:
DISTNAME= foo-X.Y
PKGREVISION= Z
=> PKGNAME= foo-X.YnbZ
Example #2:
DISTNAME= barthing-X.Y
PKGNAME= bar-X.Y
PKGREVISION= Z
=> PKGNAME= bar=X.YnbZ (!)
On subsequent changes, only PKGREVISION needs to be bumped, no more risk
of getting DISTNAME changed accidentally.
(even though that's still a bad idea), set USETOOLS=no explicitly before
including <bsd.own.mk>, and add this also to MAKE_ENV to make BSD-Makefile
based packages build properly.
use to set PKGBASE, which is used in the name of the package-specific
config directory override (PKG_SYSCONFDIR.${PKGBASE}). Prior to this, if
PKGNAME wasn't explicitly set in the package, then the override would not
work.
PKG_USERS represents the users to create for the package. It is a
space-separated list of elements of the form
user:group[:[userid][:[descr][:[home][:shell]]]]
Only the user and group are required; everything else is optional,
but the colons must be in the right places when specifying optional
bits. Note that if the description contains spaces, then spaces
should be double backslash-escaped, e.g.
foo:foogrp::The\\ Foomister
PKG_GROUPS represents the groups to create for the package. It is a
space-separated list of elements of the form
group[:groupid]
Only the group is required; the groupid is optional.
This solves the problem of what to do when there is more than one user or
group needed for a package, e.g. qmail. Also add a bit more error-checking
to the INSTALL/DEINSTALL scripts.
now work on Darwin, and then the discussion about allowing spaces in
user/group names, make these scripts work even if the inputs contain
spaces. Yes, this is overkill, but after doing all of the work, I didn't
want to waste it.
This value may be customized in various ways:
PKG_SYSCONFBASE is the main config directory under which all package
configuration files are to be found.
PKG_SYSCONFSUBDIR is the subdirectory of PKG_SYSCONFBASE under which the
configuration files for a particular package may be found.
PKG_SYSCONFDIR.${PKGBASE} overrides the value of ${PKG_SYSCONFDIR} for a
particular package.
Users will typically want to set PKG_SYSCONFBASE to /etc, or accept the
default location of ${PREFIX}/etc.
This obsoletes the use of CONFDIR, which was active for only 6 days, so no
need to have a workaround to still accept old CONFDIR settings.
names of the scripts and is no longer a MLINKS-type variable. The scripts
are copied into ${RCD_SCRIPTS_DIR} which defaults to /etc/rc.d for now.
It's unclear if Linux/Solaris would set RCD_SCRIPTS_DIR to something else.
individual defs.${OPSYS}.mk files, and use them in bsd.pkg.mk.
+ _OPSYS_HAS_MANZ defines whether or not the OS does MANZ handling as standard
+ _PREFORMATTED_MAN_DIR is the name of directory (cat or man) where
preformatted manual pages go.
Rename the internal definitions used in the generation of PLIST files to
start with '_'.
This completes the "generic" changes to bsd.pkg.mk.
many of the tasks that need to be done when package is installed or
deinstalled:
* creating user/group for the package,
* creating and removing directories with special permissions and
ownership,
* copying config files to their final locations, and removing them
at deinstall time if they don't differ from the example ones,
* reminding the package admin of files he may want to customize or
of files/directories he may want to remove.
groups. These commands follow the basic interface of the NetBSD/Solaris
useradd and groupadd programs. For platforms on which these commands don't
exist, either sysutils/user is added as a dependency, or these are set to
${FALSE}, and the package admin is responsible for creating them himself
prior to the installation of a package.
config files should go. It may be overridden on a per-package basis by
defining CONFDIR.${PKGBASE}, e.g. CONFDIR.php. ${CONFDIR} defaults to
${PREFIX}/etc, but it may be overridden in /etc/mk.conf, e.g. by setting
CONFDIR=/etc.
Packages will eventually be altered to find their config files in
${CONFDIR}.
not bsd.pkg.mk, so that the user is more aware of them (there were placeholder
examples of both definitions in bsd.pkg.defaults.mk already).
Explain PRE_ROOT_CMD a bit more throroughly, and correct an example of
its use.
Make an alternative definition for SU_CMD sync with reality.
more speedups for building packages.
Get rid of a .USE macro, and do not spawn sub-makes for the pre-, do- and
post-target stages, replacing them with standard make(1) targets.
Timing information as follows (multiple runs performed, best results taken):
800 MHz Celeron, 128 MB, local pkgsrc, local obj
scripts/, pre,do,post-*: 0.731u 0.261s 0:02.04 48.5% 0+0k 29+168io 9pf+0w
no scripts/, pre,do,post-*: 0.678u 0.242s 0:01.30 70.0% 0+0k 0+169io 0pf+0w
no scripts/, no pre,do,post-*: 0.267u 0.089s 0:00.90 37.7% 0+0k 0+155io 0pf+0w
40 MHz Sparc, 36 MB, nfs pkgsrc, local obj
scripts/, pre,do,post-*: 22.590u 6.839s 0:33.31 88.3% 0+0k 121+254io 0pf+0w
no scripts/, pre,do,post-*: 22.481u 6.442s 0:33.30 86.8% 0+0k 120+251io 0pf+0w
no scripts/, no pre,do,post-*: 8.534u 4.189s 0:16.48 77.1% 0+0k 105+242io 0pf+0w
whitespeace, followed by it's required pkgs. Make sure to look for that
whitespace, to not catch any wrong positives, e.g.
egrep "x11/kdebase.*" $DEPENDSFILE
will catch depends for both KDE1 and KDE2 and do weird things then (among
other things, think that kdelibs-2.2.1 is ok as a dependency when building
in x11/kdebase, which is certainly not!)
Eight broken pkgs less in the bulk builds by adding a single space!
(Now if adding some more would help further... :-)
lost.
However, modify previous change to let Darwin know about SHAREOWN,
SHAREGRP and SHAREMODE in a different way - no point in checking for
OPSYS here, since every OPSYS has to know about them.
implicit `-print' action is performed on bar and not on foo. Surround
the search pattern in \( ... \) and add an explict -print so that all of
the results of the find are printed.
Problem noted and patch to fix this received in private email from Stoned
Elipot <seb@netbsd.org>.
that GNU autoconf/automake are not executed during the build process, even
if the tools exist in the build environment. This prevents the build
process from overwriting any changes made to the configure script or to the
Makefile.in files.
installed JVM to use to build java-based packages.
${JAVA_HOME} is not used to select where to install java based packages. All
packages which install java .jar files should install them in
${PREFIX}/lib/java, so that they will be accessible to multiple installed
JVMs.
${.CURDIR}/pkg directory to the toplevel of the package. It remains
backward compatible with the existing system allowing a progressive
transision process. The long term goal is a reduction of overheads and
processing time when working with the cvs tree.
the scripts/ directory, it will be run automatically as part of
the build process, by bsd.pkg.mk. There are now exactly 5 packages
in pkgsrc which use this facility, and yet, for every package build,
the existence of a script is checked by bsd.pkg.mk once before the
target is executed, and once afterwards. This incurs needless
overhead.
Move the separate pre- and post- script handling out of bsd.pkg.mk into
the individual package Makefiles, where it's much more obvious what is
happening, anyway.
/usr/lib/crtbeginS.o and /usr/lib/crtendS.o make it into
{pre,post}dep_objects.
Fixes pkg/14353 from Witold J. Wnuk <witek@pd37.warszawa.sdi.tpnet.pl>
Tested as "still" working on 1.5.2.
Bump minor number of pkg and make pkgsrc depend on this version.
redefines about which buildlink.mk files would care is BUILDLINK_X11_DIR,
which points to the location of the X11R6 hierarchy used during building.
If x11.buildlink.mk isn't included, then BUILDLINK_X11_DIR defaults to
${X11BASE} (set in bsd.pkg.mk), so its value is always safe to use. Remove
the ifdefs surrounding the use of BUILDLINK_X11_DIR in tk/buildlink.mk and
revert changes to move x11.buildlink.mk before the other buildlink.mk files.
Also name the replace-libnames-configure as part of ${_CONFIGURE_PREREQ}
instead of as a prerequisite to pre-configure. This is needed so that the
replacement occurs _after_ pre-configure target is run, which may call
autoconf/automake to regenerate the configure scripts. Before this change,
the replacement would be overwritten when the configure scripts were
regenerated. This should fix a problem first noticed by Alistair Crooks
<agc@netbsd.org> in the net/mtr package.
the pre-configure target is called but before the configure script is
called, but it's added in a non-extensible way. This "stuff" is the
replace-ncurses step and the ltconfig-override step. Move these steps out
into their own targets that are named as prerequisites to the do-configure
step. The prerequisites are specified in the private variable
_CONFIGURE_PREREQ, to which other independent targets may be appended.
use X11_BUILDLINK_MK as a test value. Generally just reordering the
inclusions so that x11.buildlink.mk comes before the other buildlink.mk
files will make everthing work.
matches one of the DEPENDS, the bulk-build system looked up the
package in the INDEXFILE, then used the pkgdir returned to check
against the DEPENDS. If for some reason the package was not found
in the index file the package was left installed as 'requires
installed package'.
GROUP_SPECIFIC_PKGS into a top pkgsrc level call to make. The new way,
uses a shell 'for pkgdir in ....' and then calls a make in each pkg
directory.
This does 2 things. The first thing is that a 'build restart' starts
up _much_ faster because instead of calling 'make' for each package we've
already built and finding out they're already build, we just grep through
the list of already built pkgs. The second item (a side benefit) is that
now a progress meter is simple.
- add a progress meter to the build.
- add even more error checking.
- if something fails while extracting the DEPENDS for a particular package,
mark that package as broken and drop the DEPENDS info for it. This allows
the build to continue and properly marks the package as broken.
- if something fails while extracting the PKGNAME, also mark the pkg as broken.
- be more careful about seeing if directories exist before cd'ing to them.
Lack of such a test has caused problems elsewhere, so hopefully this will
make the system more robust.
to their names. These values shouldn't be changed by Makefiles or
buildlink.mk files; rather, they're convenience variables used exclusively
within x11.buildlink.mk.
prepending an underscore to their names. The values are not meant to be
set by Makefiles or buildlink.mk files. However, the values are exported
through CONFIGURE_ENV and MAKE_ENV so that they may be used during the
respective processes.
BUILDLINK_LDFLAGS to CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS from
bsd.buildlink.mk to bsd.pkg.mk. They're unnecessary after the recent
changes to bonobo/buildlink.mk and to libglade/buildlink.mk that removed
their settings of BUILDLINK_CPPFLAGS.
"${CPPFLAGS}", "${CXXFLAGS}" respectively "${LDFLAGS}" in "bsd.pkg.mk" and
not in "bsd.buildlink.mk" because "${BUILDLINK_CPPFLAGS}" and
"${BUILDLINK_LDFLAGS}" might get changed several times by the
"buildlink.mk" files of various packages.
after the configure step. There's a growing number of GNU configure
scripts that find a library in -L/path and automatically add -R/path to
the linker flags. We need to make sure this doesn't happen to buildlink
directories.
expanded from some expensive operation, it isn't evaluated if it's not
needed. Also fix the replace-buildlink target where we were potentially
evaluating ${REPLACE_BUILDLINK} twice when only once was enough.
MAKEFILE_PATTERNS. Also replace -R${BUILDLINK_DIR}/lib with
-R${LOCALBASE}/lib on all the REPLACE_BUILDLINK files to prevent rpath
references to ${BUILDLINK_DIR} from getting into things like config
scripts.
so that the correct setting of PKG_DBDIR is used, and the correct
pkg_info binary too, presumably.
Make show-installed-depends work on Solaris (untested) by only defining
the target if DEPENDS is defined.
installed, as it currently breaks builds that use imake. I made an
announcement on current-users and tech-pkg on this, but having the make
logic place to verify that buildlink-x11 is actually gone is better.
REPLACE_BUILDLINK
REPLACE_BUILDLINK_PATTERNS
REPLACE_BUILDLINK_SED
REPLACE_LIBNAMES
REPLACE_LIBNAMES_PATTERNS
REPLACE_LIBNAMES_SED
BUILDLINK_CONFIG_WRAPPER_SED
Also prepend an underscore to REPLACE_LIBNAME_SCRIPT as it's not a variable
we're exporting.
REPLACE_LIBNAMES_PATTERNS
REPLACE_BUILDLINK_PATTERNS
They are space-separated lists of shell glob patterns representing files
in which we substitute with REPLACE_LIBNAMES_SED (for replacing buildlink
library names with the true library names) and REPLACE_BUILDLINK_SED (for
replacing references to buildlink directories with the true install
locations). This generalizes the variables (which may still be used):
REPLACE_LIBNAMES, REPLACE_BUILDLINK,
that contained the actual filenames.
REPLACE_BUILDLINK_PATTERNS contains *.lai, *-config, *Conf.sh, and *.pc.
and use it instead. Also subsititute for library names in the installed
libtool archives. This last bit is to fix instances where "-lncurses" has
been hard-coded into *.lai files, but we are actually using -lcurses in
reality (devel/tvision is one example). Problem noted by Thomas Klausner
(hi wiz!).
where action can be "install", "package", "create user for", etc., instead
of blindly always saying "install". Define "action" before calling
${_SU_TARGET} whereever it is used.
of relying on bsd.pkg.mk to do it. This change just makes x11.buildlink.mk
more self-sufficient. Also add a warning that x11.buildlink.mk shouldn't
be included in any buildlink.mk files since what it appends to *_POST_SED
variables must come last.
the descriptions of MOTIF_TYPE and MOTIFBASE lost during the
mk.conf.example --> bsd.pkg.defaults.mk conversion. Also,
document MOTIF_TYPE_DEFAULT and MOTIF12_TYPE_DEFAULT which are
used as the final default values for MOTIF_TYPE and MOTIF12_TYPE.
Note: none of these values need to be explicitly set, as
motif.buildlink.mk will choose sensible values for all of these
variables.
This file is "included" automatically before <bsd.own.mk> includes
/etc/mk.conf, so that pkgsrc-wide default values are set.
It is now possible just to set values in mk.conf only where they differ
from the default, thereby easing the problems of updating mk.conf when
new values get added.
including motif.buildlink.mk, which contains more sophisticated and
complete logic for detecting the various Motif options that may be
installed. Though deprecated, USE_MOTIF is still recognized, though it
does no more than include motif.buildlink.mk.
(whether 2.0 or 1.2-compatible) into one file, motif.buildlink.mk.
lesstif12/buildlink.mk now assumes that if you include it, then you
actually want lesstif12.
To select that you want a Motif-1.2-compatible installation, define
USE_MOTIF12 in the package Makefile. If MOTIF12BASE is also defined, then
assume it points to a valid Motif-1.2 installation. Otherwise, auto-detect
whether /usr/dt is valid, or if we need lesstif12.
functionality. Default remains DT-Motif on Solaris. This doesn't affect
users who already have LessTif installed, as motif.buildlink.mk will use
an installed Motif package in preference to the default.
I have compiled and run every package in pkgsrc (as of today) that uses
either USE_MOTIF or motif.buildlink.mk. They all function as well or
better with OpenMotif as the installed Motif package as compared with
LessTif. There was only one small API difference I detected between
LessTif and OpenMotif in <Xm/Text.h>, where OpenMotif's Text.h includes
<stdio.h> while LessTif's does not, but the only package that this
affected (graphics/tcm) was fixed.
buildlink.mk as it uses values from the buildlink.mk for it's own value.
Also don't pass MOTIFBASE to the MAKE_ENV as it causes the correct package
buildlink.mk file to not be included.
follows:
If MOTIFBASE is set, then assume it points to a valid Motif installation.
If MOTIF_TYPE is set, then use the named Motif installation.
If neither MOTIFBASE nor MOTIF_TYPE is set, then any pre-existing Motif
installation is used, whether it is in /usr/dt or ${X11BASE} or a pkgsrc-
installed Motif.
Lastly, default to ${MOTIF_TYPE_DEFAULT}.
This makes MOTIF_TYPE behave more like XAW_TYPE in that it explicitly
chooses the Motif installation to use.
installed packages and only rebuild everything once:
STOP_DOWNLEVEL_AFTER_FIRST
if set makes "make show-downlevel" stop a bit earlier (since with the
other one below you will be only interested in the first downlevel
pkg found).
REBUILD_DOWNLEVEL_DEPENDS
if set forces the pattern match for dependencies to fail whenever the
installed pkg is not the version in the makefile (i.e. "make show-downlevel" would print a version mismatch for the dependecy). This causes all
downlevel dependencies (and everything depending on them) to be rebuild.
Enhancements, like making this all work with make command line flags and
settings in /etc/mk.conf are welcome. A way to stop "make show-downlevel"
through all upper levels of recursion imediately would be very usefull too.
BUILD_DEPENDS on libtool for the USE_LIBTOOL/non-USE_LTDL case; instead,
just depend on libtool-base (thus skipping the libtool-info and libtool
package compilation where appropriate).
USE_XAW, a package Makefile may just include mk/xaw.buildlink.mk, which
pulls in the correct buildlink.mk file depending on the value of XAW_TYPE.
A package Makefile may also rely on LIBXAW being set to the correct
libraries.
imake to be buildlinked as it's not necessary for those packages. Many
thanks to Frederick Bruckman <fredb@immanent.net> for pointing this out.
This is accomplished by ripping out all of the Makefile logic related to
buildlink-x11. It will be added back in a separate file (as noted by the
additional check for X11_BUILDLINK_MK, but will still not be the default.
* NetBSD: $LOCALBASE/share/locale -> $X11BASE/share/locale
* Linux: $LOCALBASE/share/locale -> $X11BASE/share/locale
* SunOS: $LOCALBASE/lib/locale -> $X11BASE/lib/locale
Side effect of this is that print-PLIST doesn't print locale dirs
for X apps any more.
place in the linked object, so even if the library is a symlink with a
different name from the true library, the correct soname is recorded in
the object. On a.out, there is no soname, so the linker just records the
specified library name + major number into the object, which can cause the
incorrect library name to be recorded. Fix this problem on a.out by
replacing the specified library names with the true library names in all of
the Makefiles in a post-configure step. Additional files may be added to
the list of files on which replacement is done by setting REPLACE_LIBNAMES
in each package that needs it.
This should fix pkg/13402 by John Klos <john@sixgirls.org>.
EVAL_PREFIX= FOODIR=foo
is defined, then FOODIR's value is only saved if the package foo was
found. This causes FOODIR to keep being reset until the package foo
is installed, which makes EVAL_PREFIX work properly with buildlink.mk
files. This should fix various problems people have been having with
files not being linked in when a dependency is built via a "make build"
in a package that uses that dependency further up the chain.
to remove it, then try again with 'pkg_delete -r'. This can happen when
some other out date pacakges are installed and we're trying to bulk build
a single package.
.if .if
.if . if
.else => . else
.endif . endif
.endif .endif
Patch contributed by Marc Espie <espie@liafa.jussieu.fr> in preparation of
merging latest changes with the OpenPackages project. Thanks Marc!
- The "sun-jre" and "sun-jdk" packages can now be directly selected by
setting "PKG_JVM" to "sun-jdk". "JAVA_HOME" is set to
"${LOCALBASE}/java/jre/bin" in this case which fixes PR pkg/11901
by myself.
- Only set "CLASSPATH" to "${JAVA_HOME}/lib/classes.zip" if that file
really exists.
to install things like "open.3" and "lib.3" which confuse users. Perl
ships with a documentation tool, "perldoc", for this purpose; create a
MESSAGE indicating that it should be used instead. (Perl still installs
command line program manual pages in man1.)
* Integrate bsd.perl.mk into the perl5-base build where it should have been
from the beginning. The separate perl-mk pkg makes binary packages of
perl-mk completely useless[*]. Older perl builders will not break, since
<bsd.pkg.mk> contains fallback definitions that are evaluated at pkg
build time.
=====
[*] bsd.perl.mk is tightly bound to the version of perl that is installed.
The version name "perl-mk-1.1" is completely useless as a binary pkg,
since keeping multiple binary versions of perl on a FTP server means
that one of the perl-mk's will get clobbered.
However, putting the current pkgsrc PERL5_DIST_VERS in the perl-mk pkg
is also a problem, because that doesn't necessarily reflect the
installed version of perl. Snarfing the installed version at perl-mk
build time would be even uglier, since you could not then walk the tree
without perl being installed.
The cleanest solution is to integrate bsd.perl.mk into the perl5-base
pkg, and let those who have not upgraded perl yet use the runtime
definitions in <bsd.pkg.mk>.
them in the right place. For example, a collection of binary packages can
now put uploaded with most going to the major.minor directory and the
OSVERSION_SPECIFIC ones going to the major.minor.patch directory.
still todo: the destination settings should probably be moved out of
build.conf so the same build.conf can be used by multiple machines of
different MACHINE_ARCH's at the same time. Perhaps these should be
a command line option to 'upload' instead.
addition of the xmkmf script from the XFree86-4.0.x distribution, which
understands passing -D options through to imake. Update the dependency
on buildlink-x11 in bsd.pkg.mk for packages using USE_BUILDLINK_ONLY to
>=0.5. Also, if USE_BUILDLINK_X11 is set, then refer to ${BUILDLINK_DIR}
for location of X headers and libraries.
on buildlink-x11 if USE_BUILDLINK_ONLY is defined. Pass all of
CPPFLAGS/CFLAGS/CXXFLAGS/LDFLAGS to buildlink-x11 through PKGSRC_* versions
of those values. Also add preliminary support for USE_BUILDLINK_X11 for
buildlinking X11R6 instead of USE_X11 (hi zuntum!).
