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}.
introducing the concept of a "barrier". We separate the user-invokable
targets into ones that must happen before the barrier, and ones that
must happen after the barrier. The ones that happen after the barrier
are run in a sub-make process. In this case, the targets that must
be run after the barrier are from the "wrapper" step and beyond. We
rewrite the various "flow" targets, e.g. wrapper, configure, build,
etc., so that they of the right form to use the barrier target.
This now completely removes the concept of PKG_PHASE from pkgsrc. It
is replaced with the concept of "before" and "after" the barrier, and
this state can be checked by testing for the existence of the barrier
cookie file. Because we've removed most of the recursive makes, there
is now nowhere to hook the PKG_ERROR_HANDLER.* commands, so remove
them for now.
As part of this commit, put back the logic that conditionalized the
sources for the various cookie files. Because the sources are all
"phony" targets, they were always run, regardless of whether or not
the cookie file already existed. Now, if a cookie file exists, then
that entire phase associated with that cookie file is skipped.
Lastly, fix a thinko in configure/bsd.configure.mk where setting
NO_CONFIGURE in a package Makefile would manage to skip the "wrapper"
step altogether. Fix this by correctly noting "wrapper" and not
"patch" as the preceding step to "configure".
of the logic from fetch/fetch.mk into flavor/pkg/check.mk, so that
check-vulnerable can be used as a source target.
Make check-vulnerable a source target for every phase of the build
workflow, which ensures that it is always run if the user starts a
new phase from the command line.
Fix the cookie-generation targets so that they don't append, only
overwrite to the cookie file. This works around potential problems
due to recursive makes.
Move the cookie checks so that they surround the corresponding phase
target. The presence of the cookie should now inform the make process
to avoid doing any processing of phases that occur before the phase
corresponding to the cookie.
and into their own directories. Also do some cleanups with build/_build
and pkginstall -- we get rid of _build and simply run pkginstall as
part of the "build" target.
Introduce a new mechanism to handle varying directory depths under
${WRKSRC} in which we find files to override, e.g. configure, config.*,
libtool, etc. OVERRIDE_DIRDEPTH is a package-settable variable that
specifies how far under ${WRKSRC} the various targets should look,
and it defaults to "2". We preserve the
meaning of the various *_OVERRIDE variables, so if they are defined,
then their values supersede the OVERRIDE_DIRDEPTH mechanism.
devel/tla will need to specially set OVERRIDE_DIRDEPTH to 3 (see log
for revision 1.1857 for bsd.pkg.mk -- to be done in a separate commit.
