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

120 lines
3.6 KiB
Makefile
Raw Normal View History

mk: allow "bmake clean depends" as shortcut 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.
2019-05-07 21:36:43 +02:00
# $NetBSD: package.mk,v 1.27 2019/05/07 19:36:44 rillig Exp $
Renamed package-warnings to _package-warnings, since it is a private target.
2007-03-09 00:33:35 +01:00
#
# This file provides the code for the "package" phase.
#
# Public targets:
#
# package:
# Generates a binary package.
# It will acquire elevated privileges just-in-time.
#
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 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
_PACKAGE_TARGETS+= check-vulnerable
Rename the install phase to stage-install. Introduce a new install target that defaults to either stage-install or package-install, depending on whether DESTDIR support is active and supported by the package or not.
2010-02-24 23:53:34 +01:00
_PACKAGE_TARGETS+= stage-install
prevent to generate binary package in ${PACKAGES} from the side effect of `install' with USE_DESTDIR=yes. This changes prevent to unwanted overwite of existing binary packages with test installation (`stage-install', `replace' & `undo-replace', and so on). To do both `install' and `package', you can still use `package-install' target, same as USE_DESTDIR=no.
2013-05-23 15:18:56 +02:00
_PACKAGE_TARGETS+= stage-package-create
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
_PACKAGE_TARGETS+= acquire-package-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
_PACKAGE_TARGETS+= ${_COOKIE.package}
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
_PACKAGE_TARGETS+= release-package-lock
.PHONY: package
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(package)
mk: allow "bmake clean depends" as shortcut 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.
2019-05-07 21:36:43 +02:00
. if exists(${_COOKIE.package}) && !${_CLEANING}
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
package:
@${DO_NADA}
Modify the barrier so that we always invoke the recursive make process 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.
2006-07-22 18:31:35 +02:00
. elif defined(_PKGSRC_BARRIER)
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
package: ${_PACKAGE_TARGETS}
. else
package: barrier
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-package-lock release-package-lock
acquire-package-lock: acquire-lock
release-package-lock: release-lock
mk: allow "bmake clean depends" as shortcut 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.
2019-05-07 21:36:43 +02:00
.if exists(${_COOKIE.package}) && !${_CLEANING}
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.package}:
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.package}: real-package
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
######################################################################
### real-package (PRIVATE)
######################################################################
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
### real-package is a helper target onto which one can hook all of the
### targets that do the actual packaging of the built objects.
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
###
If the package cookie file exists, then we don't need to do anything. Also, make use of a _REAL_PACKAGE_TARGETS variable just to make all of the code between the different stages more uniform.
2006-06-08 17:48:42 +02:00
_REAL_PACKAGE_TARGETS+= package-message
_REAL_PACKAGE_TARGETS+= package-all
_REAL_PACKAGE_TARGETS+= package-cookie
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: real-package
If the package cookie file exists, then we don't need to do anything. Also, make use of a _REAL_PACKAGE_TARGETS variable just to make all of the code between the different stages more uniform.
2006-06-08 17:48:42 +02:00
real-package: ${_REAL_PACKAGE_TARGETS}
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: package-message
package-message:
Use PHASE_MSG, STEP_MSG, WARNING_MSG, and ERROR_MSG in place of ECHO_MSG in various places.
2006-06-06 00:49:44 +02:00
@${PHASE_MSG} "Building binary package 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
######################################################################
### package-cookie (PRIVATE)
######################################################################
### package-cookie creates the "package" cookie file
###
.PHONY: package-cookie
package-cookie:
Replaced _PKG_SILENT and _PKG_DEBUG with RUN.
2009-03-17 23:13:36 +01:00
${RUN} ${TEST} ! -f ${_COOKIE.package} || ${FALSE}
${RUN} ${MKDIR} ${_COOKIE.package:H}
${RUN} ${ECHO} ${PKGNAME} > ${_COOKIE.package}
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
######################################################################
### The targets below are run with elevated privileges.
######################################################################
######################################################################
### package-all, su-package-all (PRIVATE)
######################################################################
### package-all is a helper target to create the binary package and
### generate any necessary warnings.
###
_PACKAGE_ALL_TARGETS+= package-create
Renamed package-warnings to _package-warnings, since it is a private target.
2007-03-09 00:33:35 +01:00
_PACKAGE_ALL_TARGETS+= _package-warnings
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
_PACKAGE_ALL_TARGETS+= error-check
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: package-all su-package-all
Add two variables to control whether make package and make clean are run with elevated privileges. Remove MAKE_PACKAGE_AS_ROOT for now, since it is not sure whether the functionality in the current form will stay and developers should spend time on the destdir support instead.
2006-10-09 13:44:06 +02:00
.if !empty(_MAKE_PACKAGE_AS_ROOT:M[Yy][Ee][Ss])
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
package-all: su-target
Added a new variable MAKE_PACKAGE_AS_ROOT that controls whether the package needs to be packed by root or whether the unprivileged user can do that as well. Most packages don't need root privileges, but the default value is nevertheless "yes" to not break too many existing packages. pkgsrc users are encouraged to add the following to their mk.conf: MAKE_PACKAGES_AS_ROOT?= no The "?=" operator here is important because after the testing phase, this variable is only intended to be set by packages. If "=" would be used instead, packages could not override the value.
2006-10-08 22:31:38 +02:00
.else
Add two variables to control whether make package and make clean are run with elevated privileges. Remove MAKE_PACKAGE_AS_ROOT for now, since it is not sure whether the functionality in the current form will stay and developers should spend time on the destdir support instead.
2006-10-09 13:44:06 +02:00
package-all: su-package-all
Added a new variable MAKE_PACKAGE_AS_ROOT that controls whether the package needs to be packed by root or whether the unprivileged user can do that as well. Most packages don't need root privileges, but the default value is nevertheless "yes" to not break too many existing packages. pkgsrc users are encouraged to add the following to their mk.conf: MAKE_PACKAGES_AS_ROOT?= no The "?=" operator here is important because after the testing phase, this variable is only intended to be set by packages. If "=" would be used instead, packages could not override the value.
2006-10-08 22:31:38 +02:00
.endif
Add two variables to control whether make package and make clean are run with elevated privileges. Remove MAKE_PACKAGE_AS_ROOT for now, since it is not sure whether the functionality in the current form will stay and developers should spend time on the destdir support instead.
2006-10-09 13:44:06 +02:00
su-package-all: ${_PACKAGE_ALL_TARGETS}
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
######################################################################
### package-create (PRIVATE, override)
######################################################################
### package-create creates the binary package. This should be overridden
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
### per package system format.
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
###
.if !target(package-create)
.PHONY: package-create
package-create:
@${DO_NADA}
.endif
Renamed package-warnings to _package-warnings, since it is a private target.
2007-03-09 00:33:35 +01:00
# Displays warnings about the binary package.
#
_package-warnings: .PHONY
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
.if defined(NO_BIN_ON_CDROM)
1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which resulted 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".
2006-06-07 12:04:03 +02:00
@${WARNING_MSG} "${PKGNAME} may not be put on a CD-ROM:"
@${WARNING_MSG} ${NO_BIN_ON_CDROM:Q}
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
.endif
.if defined(NO_BIN_ON_FTP)
1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which resulted 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".
2006-06-07 12:04:03 +02:00
@${WARNING_MSG} "${PKGNAME} may not be made available through FTP:"
@${WARNING_MSG} ${NO_BIN_ON_FTP:Q}
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
.endif
.if defined(ABI_DEPENDS) && !empty(USE_ABI_DEPENDS:M[Nn][Oo])
1.) Remove all instances of '@${WARNING_MSG} "Warning: ...' which resulted 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".
2006-06-07 12:04:03 +02:00
@${WARNING_MSG} "ABI dependency recommendations are being ignored!"
@${WARNING_MSG} "${PKGNAME} should not be uploaded nor"
@${WARNING_MSG} "otherwise be used as a binary package!"
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
.endif
Reference in a new issue Copy permalink