variable is much more comfortable than specifying all the directories in
INSTALLATION_DIRS that using such a long name for it feels like a
punishment. It also doesn't look nice in the package Makefiles, for
example:
old:
INSTALLATION_DIRS= bin ${PKGMANDIR}/man1 ${PKGMANDIR}/man8
new:
AUTO_MKDIRS= yes
The variable INSTALLATION_DIRS_FROM_PLIST will be deprecated slowly.
in the definition of INSTALLATION_DIRS, where a short man/ would be much
shorter. Since we already have that man-transforming magic in some other
places of pkgsrc, it's also here.
While here, documented INSTALLATION_DIRS and
INSTALLATION_DIRS_FROM_PLIST so they are found by "bmake help".
- check-perms.mk was not DESTDIR aware, prefix files before passing it
to the directory extraction
- PKG_FILELIST_CMD was calling pkg_info, which is fine for normal
installation, but fails of course for DESTDIR. Just drop the @ lines
from ${_DEPENDS_PLIST} and use that.
- To make he former work, ensure that _flavor-generate-metadata is part
of _INSTALL_ALL_TARGETS. It was normally a dependency of
_flavor-register, but that is skipped for DESTDIR.
- Remove ${_DEPENDS_PLIST} when running install-clean.
contains files that are generated during the "install" phase. This
should fix the problem where PLIST modifications were ignored if the
PLIST was modified between a "make deinstall" and a "make reinstall".
install/install.mk to check/check-shlibs.mk.
Renamed check-shlibs to _check-shlibs. Since it had been declared as
"private" before, this will not break anything.
don't use mkdir, as the latter uses the group permissions of the
parent directory under BSDs, resulting in group leaks for
USE_DESTDIR=yes. Discussed with agc@.
need to specify INSTALLATION_DIRS itself. Instead, the list is generated
from the static PLIST files. Like for INSTALLATION_DIRS, mtree is
disabled when this variable is set.
"make install". That way, packages don't have to say:
INSTALL_MAKE_FLAGS+= ${MAKE_FLAGS} foo=bar,
instead it suffices to say
INSTALL_MAKE_FLAGS+= foo=bar,
which is also more appropriate since multiple files (Makefile,
Makefile.common, options.mk, *.mk) don't need to care about whether
INSTALL_MAKE_FLAGS already includes MAKE_FLAGS or not.
Note: It is no longer possible to override MAKE_FLAGS completely. But
except for some exotic platforms, the default value is empty anyway.
Packages may set PKG_DESTDIR_SUPPORT to either "destdir" or
"user-destdir" to flag support for this, following the same
rules as PKG_INSTALLATION_TYPES (e.g. define before first include
of bsd.prefs.mk).
The user activates it via USE_DESTDIR. When set to "yes",
packages with "user-destdir" are handled as "destdir".
The installation of the package will not go to ${LOCALBASE},
but a subdirectory of ${WRKDIR} instead. pre/post install scripts are
not run and the package is not registered either. A binary package
can be created instead to be installed normally with pkg_add.
For "user-destdir" packages, everything is run as normal user and
ownership is supposed to be correctled by pkg_create later. Since
the current pkg_install code uses pax and it doesn't allow overwriting
owners, this does not work yet.
For "destdir" packages, installation, packaging and cleaning is run as
root.
This commit does not change the handling of DEPENDS_TARGET or
bin-install to allow recursive usage.
INSTALLATION_DIRS but a regular file of the same name already exists,
the BSD install(1) program doesn't care but exits successfully.
To avoid much more confusing error messages, this is checked here, and a
_good_ error message is printed.
Added two targets acquire-localbase-lock and release-localbase-lock,
which mark the complete LOCALBASE directory as locked, so that multiple
packages cannot run the install, deinstall or bin-install targets at the
same time.
The install target aquires locks in both WRKSRC and LOCALBASE, the other
two targets only need the LOCALBASE lock, since they may be run without
WRKSRC being present on the system.
locking.mk must be included before tools.mk and the PKG_FAIL_REASON
check.
environment ${PKGSRC_MAKE_ENV} is also passed along. Create a
convenience variable RECURSIVE_MAKE that does exactly this and that
can be used in place of MAKE when invoking make recursively.
Use RECURSIVE_MAKE everywhere in pkgsrc/mk that we invoke make
recursively.
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.
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.
which are invoked in recursive make calls for the "install" and
"package" targets respectvely. These recursive make calls prevent
the top-level make from seeing all of the targets and computing a full
dependency graph, so it becomes possible for some targets to be invoked
more than once. This change passes enough information along to the
recursive make calls and ensures that the source targets for the real-*
targets are only invoked once.
are generated for a target and output them all at once at the conclusion
of the target's invocation. The implementation is in bsd.pkg.error.mk,
which defines a macro target "error-check" that will print out any
non-empty warning and error files in ${WARNING_DIR} and ${ERROR_DIR}
and exit appropriately if there were errors.
Convert some targets that were just long sequences of ${ERROR_MSG} or
${WARNING_MSG} within a single shell statement to use the new delayed
error output via error-check.
Modify the compiler "fail" wrappers for C++ and Fortran to be less
verbose during invocation. Instead collect the warnings and only
print them at the end of the completed phase, e.g. after "configure"
and/or "build" completes.
in error message like 'WARNING: Warning: ...'.
2.) Replace "WARN_MSG" with "WARNING_MSG" which makes the "make package"
target work again for restricted packages like "acroread7".
if PKG_SKIP_REASON or PKG_FAIL_REASON is defined. This commit adds
!target(...) guards around those target definitions to avoid "duplicate
target definition" warnings.
