pkgsrc/mk/install/bsd.install-vars.mk

59 lines
1.9 KiB
Makefile
Raw Normal View History

# $NetBSD: bsd.install-vars.mk,v 1.6 2007/04/19 16:52:03 joerg 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
#
# This Makefile fragment is included separately by bsd.pkg.mk and
# defines some variables which must be defined earlier than where
# bsd.install.mk is included.
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-settable variables:
#
# INSTALLATION_DIRS_FROM_PLIST
# If set to "yes", the static PLIST files of the package will
# be used to determine which directories need to be created before
# the "real" installation should start.
#
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(USE_MTREE)
USE_TOOLS+= mtree:bootstrap
.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
# If MANZ is defined, then we want the final man pages to be compressed.
# If MANZ is not defined, then we want the final man pages to be
# uncompressed.
#
# We need to figure out if during installation, we need either gunzip
# or gzip to decompress or compress the installed man pages. If a
# package sets MANCOMPRESSED to "yes" or "no", then it's an indication
# to the install code that the package itself installed the man pages
# either compressed or uncompressed. If a package sets
# MANCOMPRESSED_IF_MANZ, then the package uses BSD-style makefiles,
# so we need to determine if the BSD-style makefile causes the man
# pages to be compressed or not.
#
.if !defined(_MANCOMPRESSED)
. if defined(MANCOMPRESSED) && !empty(MANCOMPRESSED:M[yY][eE][sS])
_MANCOMPRESSED= yes
. else
_MANCOMPRESSED= no
. endif
. if defined(MANCOMPRESSED_IF_MANZ) && defined(PKGMAKECONF)
_MANCOMPRESSED!= \
{ ${ECHO} ".include \""${PKGMAKECONF:Q}"\""; \
${ECHO} "all:"; \
${ECHO} ".if defined(MANZ)"; \
${ECHO} " @${ECHO} yes"; \
${ECHO} ".else"; \
${ECHO} " @${ECHO} no"; \
${ECHO} ".endif"; \
} | ${MAKE} -f - all
. endif
.endif
_MANZ= ${MANZ:Dyes:Uno}
MAKEVARS+= _MANCOMPRESSED _MANZ
.if !empty(_MANCOMPRESSED:M[yY][eE][sS]) && empty(_MANZ:M[yY][eE][sS])
USE_TOOLS+= gunzip
.endif
.if empty(_MANCOMPRESSED:M[yY][eE][sS]) && !empty(_MANZ:M[yY][eE][sS])
USE_TOOLS+= gzip
.endif