I am under the impression we use _THING to mean "defined by the
implementation", which would be similar to the C meaning of __ prefix,
rather than "private to this file".
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.
This allows setting MAKE_JOBS high and then setting e.g.
MAKE_JOBS.emulators/qemu=2 (or some such low value) to keep it from
thrashing during build.
Discussed/approved on tech-pkg two months ago and then I forgot to
actually commit it.
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).
If ${_USE_NEW_PKGINSTALL} is "yes", then use the new "pkgtasks",
"init", and "pkgformat/pkg"-scripts frameworks instead of the
existing "pkginstall" framework.
By default pkgsrc uses LOCABASE/gnu as a prefix for packages to install
native versions of GNU tools, which are them symbolically linked back to
the 'g' versions of the files in LOCALBASE, and users can then add
LOCALBASE/gnu/bin to PATH to pick up those tools.
On systems where the GNU environment is desired, PKGGNUDIR now allows
users to install the non-'g' files directly into LOCALBASE, making them
the default without having to alter PATH, whilst retaining the 'g' files
in order to ensure dependencies and tool paths remain the same.
is a new target "show-all" that fits to the existing "debug",
"show-tools", "show-vars" targets. It prints a list of the variables
that make up the public interface to pkgsrc. Running this target is
especially useful if you want to do some things, you know that they must
have been implemented but you don't know what it is called. It also
shows the "class" of a variable (user-defined, package-defined,
system-defined).
is no longer available to packages that set NO_BUILD.
Added the variable BUILD_ENV_SHELL, since I prefer a comfortable shell
over /bin/sh for interactive work.
since according to the comment in check/bsd.check.mk, they belong there.
Added a new check for all C and C++ header files to make sure they don't
contain strings like ${prefix} or ${exec_prefix}, which is currently a
problem with sysutils/dbus and has been noticed in PR 35019. This check
is disabled by default since I don't know anything about possible false
positives, but I plan to enable it for PKG_DEVELOPERs after some
testing.
Added two names for hooks that are placed in the configure and in the
build phase. Now the checks look more like becoming something one could
call a framework, sharing a common structure and a documented interface.
common MAKE_FLAGS instead of overriding them, to align with the new
definition of INSTALL_MAKE_FLAGS.
The packages that override BUILD_MAKE_FLAGS don't have to be changed,
since they prepended MAKE_FLAGS to BUILD_MAKE_FLAGS, except for less
than five cases. In those cases, it may well have been unknown to the
package author that MAKE_INSTALL_FLAGS had been an overriding variable
instead of one whose value is just appended to something else.
Some packages (postgresql, some compilers, Java environments, qcad) are
using code copied from build.mk. These packages will have to be adjusted
to the new variable definitions. To make this change easier, two new
variables BUILD_MAKE_CMD and TEST_MAKE_CMD have been introduced that
contain the complete command that makes up the call to make(1). This
prevents further code duplication.
target.
MAKE_JOBS is undefined by default. You can test this by setting
in mk.conf: MAKE_JOBS=5 for example.
Some package just won't build correctly with this -- these individual
packages can set MAKE_JOBS_SAFE=no to disable it.
This is based on discussion from last December 2005. Some pkgsrc
users are using ideas like this.
Note I have been using this since December 2005 on various single
processor and multiprocessor systems. (Once I kept some stats on
performance but have misplaced that now.) I haved tested this with
many packages (but not a bulk build) on Linux, NetBSD and DragonFly.
This commit doesn't include the commits for the MAKE_JOB_SAFE. As
this is experimental it needs more testing. Some examples of problems
are: comms/lrzsz, databases/gramps2, editors/vim, graphics/MesaLib,
graphics/netpbm, net/bind9, print/ghostscript-esp, textproc/libxml,
and www/lynx.
when passing through the barrier. This ensures the PATH (passed via
PKGSRC_MAKE_ENV) is correctly set for all phases after the barrier.
This fixes a bug in "interactive" pkgsrc use, where if you have no
work directory and type "make build && make install", then the "install"
step does not have a PATH set to include all the wrapper and tools
directories.
to all internal recursive make processes. As such, rename it to
"PKGSRC_MAKE_ENV".
XXX Note, some of the usage of this variable in package Makefiles seems
XXX incorrect. They probably want "MAKE_ENV", which is the environment
XXX passed to the make process when running "make" within ${WRKSRC}.
