"Building for WWW" (pops up in two different ports) "Installing for
web2c-6.1" (ditto), which aren even't reminiscent of the port's real
name.
Sorry jmz, please don't go fix the print Makefiles' own messages.
We are going to take them out after we do the great bsd.port.mk
update anyway.
the top level and have the build-package sequence of each port work
together.
For the old behavior (i.e, just go ahead and blindly pack everything up,
regardless of the contents of work/), there is a new target "repackage".
Since "build" depends on "configure", which depends on "patch", etc.,
this shouldn't disrupt any Makefile that doesn't break the dependency
chain.
The old behavior was very annoying because when I did a "make -k",
it would still try to go configure and build even if the extraction
failed.
all .tgz files go to /usr/ports/packages/.packages, and a relative
symlink is created for every item in CATEGORIES...i.e., if "CATEGORIES
= foo bar", then /usr/ports/packages/{foo,bar}/pkgname.tgz both point
to /usr/ports/packages/.packages/pkgname.tgz.
Suggested by: jkh
New variables:
PATCH_SITES: patch equivalent of MASTER_SITES, overridable with
. MASTER_SITE_OVERRIDE.
PATCHFILES: Additional files to fetch and give to patch before
. applying the ones in patches/patch-*. If name ends
. with ".gz" or ".Z", it will be piped through zcat first.
Plus PATCH_DIST_STRIP and PATCH_DIST_ARGS that serve the same functions
as PATCH_STRIP and PATCH_ARGS for patches in patches/patch-*.
In the documentation and echo messages, I used the term "distributed
patches" and "FreeBSD patches" to refer to ${PATCHFILES} and patches/patch-*.
If you can come up with better names, by all means go ahead and fix them.
"grep PATCH /usr/ports/*/*/Makefile" reveals seven ports (mule, jless,
jtcl, jtk, dgd, less, color_xterm, gee I wonder why I'm the one who
implemented this) that can benefit from this. I'm now diving headlong
into /usr/ports to fix their Makefiles.
installation script, DEINSTALL for the deinstallation script, and
REQ for the requirement script, will be added with appropriate
flags to PKG_ARGS if they exist under pkg/.
have three variables:
EXEC_DEPENDS - A list of "prog:dir" pairs of other ports this
package depends on. "prog" is the name of an
executable. make will search your $PATH for it and go
into "dir" to do a "make all install" if it's not found.
LIB_DEPENDS - A list of "lib:dir" pairs of other ports this package
depends on. "lib" is the name of a shared library.
make will use "ldconfig -r" to search for the
library. Note that lib can be any regular expression,
and you need two backslashes in front of dots (.) to
supress its special meaning (e.g., use
"foo\\.2\\.:${PORTSDIR}/utils/foo" to match "libfoo.2.*").
DEPENDS - A list of other ports this package depends on being
made first. Use this for things that don't fall into
the above two categories.
DEPENDS behaves exactly like before, so old Makefiles will still work
the same. The two variables are lists of pairs as described above.
For instance, if your program depends on unzip and libjpeg.5.*, use
the following definitions:
EXEC_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
LIB_DEPENDS= jpeg\\.5\\.:${PORTSDIR}/graphics/jpeg
gmake:${PORTSDIR}/utils/gmake is automatically added to EXEC_DEPENDS
if USE_GMAKE is defined.
If NO_DEPENDS is defined, the list will just be printed out one by one.
2) Change INSTALL_MANPAGES to NO_INSTALL_MANPAGES and document it
3) Add a PKGNAME variable to allow the package name
not to be dictated by stupid DISTNAMEs
4) Add a PATCH_DEBUG option and a slight change to the default
patch system - add --forward to help ensure correct patching
Further investigation showed that prefix was erroneously set to /usr/local
for X11 based ports as well, when the assumption was that they'd really go
into ${X11BASE} (an /etc/make.conf variable that the user's free to set).
Set X11BASE to /usr/X11R6 if the user hasn't already, and assume that
the user really wants prefix to point there when the port is XMKMF based.
MASTER_SITE_OVERRIDE - If set in the environment, will override everyone's
MASTER_SITES settings. Useful if you'd prefer to point to a
distfiles repository somewhere closer.
MASTER_SITE_FREEBSD - Sets OVERRIDE to be FreeBSD's own master repository.
about them.. :-) The patches/* won't work, it needs to be patches/patch-*
to avoid catching things like CVS files when working with a checked-out
copy of ports! Whoops!
1. Make build rely on a BUILD_COOKIE now. I'm tired of builds
being redone gratuitously while I'm trying to debug a tree build
problem.
2. Remove all the literal `touch -f' commands and indirect them through
variables. This lets you "leave tracks" in different ways, depending
on the medium. Just part 1 of my planned changes to make builds
directly off the CD work.
is an interactive port, and requires user input somewhere along
the way (either fetching, configuring, building or installing).
If the user then sets BATCH in their environment, this port will be
skipped. If the user sets INTERACTIVE, then ONLY those ports marked
interactive are run (allowing one to do all ports in two passes).
If the user sets both BATCH and INTERACTIVE, then a metal claw extends
from the CRT and brutally yanks their nose off.
install cookie work any other way (perhaps I'm just being stupid).
In any case, INSTALL_COOKIE now works as advertised, and prevents duplicate
installations. pre-install users will have to keep their own cookies if
they wish to avoid duplicate installations, or tell me how to make the
rules run properly.
1. Make DEPENDS fully qualified, and not implictly assume relative
to ${PORTSDIR}. This allows more arbitrary dependencies to be
specified. This also means that DEPENDS= x11/foo needs to be changed
to DEPENDS= ${PORTSDIR}/x11/foo in any Makefiles. I'll try to do
these changes myself.
2. Add an option NO_DEPENDS to disable the automagic building of depended
ports.
Submitted by: rww
Make DEPENDS now does a `make is_depended' in the target port.
This defaults to `all install' globally, but can be overriden locally
by a port if it wants to do different things when other ports depend on it.
the light. `env' can be used to pass environment variables to shell
scripts this way, which means that all *configure/post-build scripts
_no longer take any arguments_; everything they should need (and more)
is now available in the environment. I'm working now to adapt the older
shell scripts over, but if you want beat me to it on some of your own
ports, don't let me stop you! :)
Submitted by: witr
Satoshi Asami
Jordan K. Hubbard
Gary Palmer
Andreas Schulz
Jeffrey Hsu
Poul-Henning Kamp
Andrey A. Chernov
Jean-Marc Zucconi