Build depends are target packages that are needed at build-time for,
e.g., static libraries to link against, header files to include, &c.
Tool depends are native packages that are needed at build-time for,
e.g., compilers/linkers/&c. to run.
ok agc
This is from Anton Panev's GSoC 2011 project to add RPM and DPKG
support to pkgsrc. (I am not adding that further support in this
commit.)
This is just a rename of the existing functionality. Now it will
be easy to test the GSoC work by simply putting in a single
directory (such as "rpm" or "deb"). See
http://addpackageforma.sourceforge.net/ for some details.
This is from Anton's CVS, but I made some minor changes:
- changed plural pkgformats to singular pkgformat (to be consistent)
- fixed a few places (in comments) that were missed
- catch up on some additions to flavor not in the pkgforma cvs:
PKGSRC_SETENV and _flavor-destdir-undo-replace and
undo-destdir-replace-install.
phase pkg_install-depends before bootstrap-depends that just tries to
install a new pkg_install if the current version is too old. Still
keep it as bootstrap dependency for the bulk build code.
For NetBSD, PKG_TOOLS_BIN has to be computed in shell code due to a make
bug.
OK: jlam@
dependency installation, it occured to me that "make depends" doesn't
run the bootstrap-depends target correctly anymore. A deeper analysis
didn't show why it happened to work as it is only requested explicitly
by fetch. It wasn't an issue as all bootstrap dependencies were checked
again before, but fix this correctly by listening as dependency of
depends as well.
trace the dependency information. This is computed and stored in
.depends directly now before anything else is done. The output is locked
and the locking is supposed to work before the bootstrap-depends are
installed.
Add a new hook for flavors after all dependencies are added and before
the depends-cookie is created. Use this to compute which package is used
to fulfill each dependency and store it in .rdepends. Adjust
register-dependencies and some other places to use this information
directly instead of recomputing it all the time.
The code to list all dependencies and to recursively install missing
ones is moved to a separate shell script. This makes it easier to
understand what is going on and extend them later.
Change the calling of pkg_create to prepend the dependencies directly to
the passed-in PLIST and not via -P and -T. This is in preperation of
changing the way they are stored in the packages.
Discussed with, recieved minor disagreement about install-dependencies,
but otherwise OKed by jlam.
revision 1.10. Use a new name that is more aligned with current
variable-naming methodology: SKIP_DEPENDS. It's a YesNo variable that
defaults to "no".
This functionality is just way too useful to pkgsrc developers to lose.
stages, and that installs dependencies listed in BOOTSTRAP_DEPENDS.
The bootstrap-depends step works just like the normal depends step
and honors the value of DEPENDS_TARGET. It's now possible to add
dependencies solely to facilitate fetching the distfiles, e.g.
BOOTSTRAP_DEPENDS+= curl-[0-9]*:../../www/curl
* Teach the tools framework about ":bootstrap" as a tools modifier
which indicates the tool should be added as a dependency via
BOOTSTRAP_DEPENDS.
* Add "digest" to the tools framework.
* Use USE_TOOLS+=digest:bootstrap to force pkgsrc to install digest
before anything else. Get rid of unused "uptodate-digest" target
and related digest version-checking code.
* Finish the refactoring work: split checksum-related code out of
bsd.pkg.mk and into pkgsrc/mk/checksum and replace the "checksum"
target command list with a script that does all the real work.
* Make DIGEST_ALGORITHMS and PATCH_DIGEST_ALGORITHM into private
variables by prepending them with an underscore. Also, rename
_PATCH_DIGEST_ALGORITHM to _PATCH_DIGEST_ALGORITHMS and adjust the
makepatchsum target to allow that variable to contain a list of
algorithms, all of which are used when creating the patch checksums
for ${DISTINFO_FILE}.
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.
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.
bsd.pkg.mk. They didn't actually need to be defined in bsd.prefs.mk,
just somewhere before the "main" bsd.<phase>.mk files were included.
This moves some conditional (?=) definitions back into bsd.pkg.mk so
they won't conflict with any conditional definitions in package
Makefiles.
This should fix the "checksum" problems in lang/php-gd as noted here:
http://mail-index.netbsd.org/pkgsrc-users/2006/06/05/0012.html
where EXTRACT_SUFX had the wrong value due to the order in while *.mk
files were included.
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.
than pkgsrc's current one. This is an important lead-up to any project
that redesigns the pkg_* tools in that it doesn't tie us to past design
(mis)choices. This commit mostly deals with rearranging code, although
there was a considerable amount of rewriting done in cases where I
thought the code was somewhat messy and was difficult to understand.
The design I chose for supporting multiple package system flavors is
that the various depends, install, package, etc. modules would define
default targets and variables that may be overridden in files from
pkgsrc/mk/flavor/${PKG_FLAVOR}. The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work. The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support. Currently,
I only have "pkg" which represents the current pkgsrc-native package
flavor. I've separated out most of the code where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files, and
placed it into pkgsrc/mk/flavor/pkg.
There are several new modules that have been refactored out of bsd.pkg.mk
as part of these changes: check, depends, install, package, and update.
Each of these modules has been slimmed down by rewriting them to avoid
some recursive make calls. I've also religiously documented which
targets are "public" and which are "private" so that users won't rely
on reaching into pkgsrc innards to call a private target.
The "depends" module is a complete overhaul of the way that we handle
dependencies. There is now a separate "depends" phase that occurs
before the "extract" phase where dependencies are installed. This
differs from the old way where dependencies were installed just before
extraction occurred. The reduce-depends.mk file is now replaced by
a script that is invoked only once during the depends phase and is
used to generate a cookie file that holds the full set of reduced
dependencies. It is now possible to type "make depends" in a package
directory and all missing dependencies will be installed.
Future work on this project include:
* Resolve the workflow design in anticipation of future work on
staged installations where "package" conceptually happens before
"install".
* Rewrite the buildlink3 framework to not assume the use of the
pkgsrc pkg_* tools.
* Rewrite the pkginstall framework to provide a standard pkg_*
tool to perform the actions, and allowing a purely declarative
file per package to describe what actions need to be taken at
install or deinstall time.
* Implement support for the SVR4 package flavor. This will be
proof that the appropriate abstractions are in place to allow
using a completely different set of package management tools.
