kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/mk/depends/depends.mk

65 lines
2 KiB
Makefile
Raw Normal View History

Revert previous commit
2014-01-14 13:28:47 +01:00
# $NetBSD: depends.mk,v 1.18 2014/01/14 12:28:47 cheusov Exp $
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
######################################################################
### depends (PUBLIC)
######################################################################
### depends is a public target to install missing dependencies for
### the package.
###
_DEPENDS_TARGETS+= acquire-depends-lock
Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private variables so there are no user-visible changes. This change just makes it a little easier to write for loops.
2006-07-07 23:24:27 +02:00
_DEPENDS_TARGETS+= ${_COOKIE.depends}
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
_DEPENDS_TARGETS+= release-depends-lock
.PHONY: depends
Allow overrides of the public targets, e.g. "install", "package", etc. 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.
2006-06-05 19:41:11 +02:00
.if !target(depends)
Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private variables so there are no user-visible changes. This change just makes it a little easier to write for loops.
2006-07-07 23:24:27 +02:00
. if exists(${_COOKIE.depends})
Make the check-vulnerable target more self-sufficient, by moving some 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.
2006-07-05 11:08:35 +02:00
depends:
@${DO_NADA}
Flatten out recursive makes into a single re-invocation of make by 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".
2006-07-06 00:21:02 +02:00
. else
depends: ${_DEPENDS_TARGETS}
Make the check-vulnerable target more self-sufficient, by moving some 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.
2006-07-05 11:08:35 +02:00
. endif
Allow overrides of the public targets, e.g. "install", "package", etc. 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.
2006-06-05 19:41:11 +02:00
.endif
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
.PHONY: acquire-depends-lock release-depends-lock
acquire-depends-lock: acquire-lock
release-depends-lock: release-lock
Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private variables so there are no user-visible changes. This change just makes it a little easier to write for loops.
2006-07-07 23:24:27 +02:00
.if exists(${_COOKIE.depends})
${_COOKIE.depends}:
Flatten out recursive makes into a single re-invocation of make by 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".
2006-07-06 00:21:02 +02:00
@${DO_NADA}
.else
Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private variables so there are no user-visible changes. This change just makes it a little easier to write for loops.
2006-07-07 23:24:27 +02:00
${_COOKIE.depends}: real-depends
Flatten out recursive makes into a single re-invocation of make by 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".
2006-07-06 00:21:02 +02:00
.endif
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
Make use of a "real-depends" helper target to hook all of the other targets onto, and move the depends-message further down so that if the depends cookie file already exists, then no message is outputted.
2006-06-08 17:45:06 +02:00
######################################################################
### real-depends (PRIVATE)
######################################################################
### real-depends is a helper target onto which one can hook all of the
### targets that do the actual dependency installation.
###
Move handling of pkg_install version into flavor. Add an explicit 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@
2008-04-03 16:07:51 +02:00
_REAL_DEPENDS_TARGETS+= ${_PKG_INSTALL_DEPENDS:Dpkg_install-depends}
While investigating xtraeme's bug report about duplicate running of the 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.
2007-05-22 21:04:24 +02:00
_REAL_DEPENDS_TARGETS+= bootstrap-depends
Make use of a "real-depends" helper target to hook all of the other targets onto, and move the depends-message further down so that if the depends cookie file already exists, then no message is outputted.
2006-06-08 17:45:06 +02:00
_REAL_DEPENDS_TARGETS+= depends-message
_REAL_DEPENDS_TARGETS+= pre-depends-hook
Rename "flavor" to "pkgformat". 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.
2011-10-15 02:23:07 +02:00
_REAL_DEPENDS_TARGETS+= _pkgformat-install-dependencies
_REAL_DEPENDS_TARGETS+= _pkgformat-post-install-dependencies
Make use of a "real-depends" helper target to hook all of the other targets onto, and move the depends-message further down so that if the depends cookie file already exists, then no message is outputted.
2006-06-08 17:45:06 +02:00
_REAL_DEPENDS_TARGETS+= depends-cookie
Introduce the capability to gather all the warnings and errors that 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.
2006-06-09 15:59:06 +02:00
_REAL_DEPENDS_TARGETS+= error-check
Make use of a "real-depends" helper target to hook all of the other targets onto, and move the depends-message further down so that if the depends cookie file already exists, then no message is outputted.
2006-06-08 17:45:06 +02:00
.PHONY: real-depends
real-depends: ${_REAL_DEPENDS_TARGETS}
.PHONY: depends-message
depends-message:
@${PHASE_MSG} "Installing dependencies for ${PKGNAME}"
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
######################################################################
### pre-depends-hook (PRIVATE, override, hook)
######################################################################
### pre-depends-hook is a generic hook target that is run just before
Rename "flavor" to "pkgformat". 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.
2011-10-15 02:23:07 +02:00
### dependencies are installed for _pkgformat-install-dependencies.
First pass at implementing support for package system flavors other 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.
2006-06-04 01:11:42 +02:00
###
.PHONY: pre-depends-hook
pre-depends-hook:
@${DO_NADA}
Reference in a new issue Copy permalink