Makefile revision 1152
792N/A############################################################################### 792N/A# Makefile for X Consolidation packages 792N/A# Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. 792N/A# Permission is hereby granted, free of charge, to any person obtaining a 792N/A# copy of this software and associated documentation files (the "Software"), 792N/A# to deal in the Software without restriction, including without limitation 792N/A# the rights to use, copy, modify, merge, publish, distribute, sublicense, 792N/A# and/or sell copies of the Software, and to permit persons to whom the 792N/A# Software is furnished to do so, subject to the following conditions: 792N/A# The above copyright notice and this permission notice (including the next 792N/A# paragraph) shall be included in all copies or substantial portions of the 792N/A# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 792N/A# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 792N/A# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 792N/A# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 792N/A# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 792N/A# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 792N/A# DEALINGS IN THE SOFTWARE. 792N/A############################################################################### 792N/A# Please read the comments in it and the accompanying README in ON for many 792N/A# Major differences in the X implementation: 792N/A# - X only supports building one repo, not redist + extra 792N/A# - X only supports building packages on the same platform as the binaries, 792N/A# no cross-platform packaging 792N/A# - X has no bfu legacy to deal with 792N/A# - ON has all manifests in one directory, X splits into current & legacy 792N/A### Include common definitions 792N/A# We don't yet support building packages cross-architecture, but would 792N/A# need this if we ever did. (See "Cross platform packaging notes" in 792N/A# Map X makefile names to the ones used in the rules copied from ON 792N/A# More to be updated if we ever decide to support building cross-platform 792N/A# Map the V=1 style of enabling more verbose build messages used in the 792N/A# You can enable verbose output with either V=1 or PKGDEBUG="" 792N/A# Commands used in rules copied from ON 792N/A# To suppress package dependency generation on any system, regardless 792N/A# of how it was installed, set SUPPRESSPKGDEP=true in the build 792N/A# The packages directory will contain the processed manifests as 792N/A# direct build targets and subdirectories for package metadata extracted 792N/A# incidentally during manifest processing. 792N/A# Nothing underneath $(PDIR) should ever be managed by SCM. 792N/A# By default, PKGS will list all manifests. To build and/or publish a 792N/A# subset of packages, override this on the command line or in the 792N/A# build environment and then reference (implicitly or explicitly) the all 792N/A# Track the synthetic manifests separately so we can properly express 792N/A# build rules and dependencies. The synthetic and real packages use 792N/A# different sets of transforms and macros for pkgmogrify. 792N/A# Any given package list may be empty, but we can only determine that 792N/A# dynamically, so we always generate all lists. 792N/A# The meanings of each package status are as follows: 792N/A# ---------- ---------------------------------------------------- 792N/A# noincorp Do not include in incorporation or group package 792N/A# grouponly Include in group package, but not incorporation 792N/A# obsolete Include in incorporation, but not group package 792N/A# renamed Include in incorporation, but not group package 792N/A# current Include in incorporation and group package 792N/A# Since the semantics of the "noincorp" package status dictate that 792N/A# such packages are not included in the incorporation or group packages, 792N/A# there is no need to build noincorp package lists. 792N/A# Since packages depend on their incorporation, noincorp necessarily 792N/A# implies nodepend, or it would inadvertently pull in other packages. 792N/A# Manifests are in either manifests or legacy directory - merge in $(PDIR) 792N/A### Additional metadata generation 792N/A# This should eventually move into pkg publication 792N/A @
print "## Generating font metadata in $(@F)" ### Manifest mogrification # RELEASE = uname -r for the target release # Generate pkgmogrify transform file with correct build version info in # Build number is derived from last nv_XXX tag in hg log @
print "## Substituting build info in versions transformation template" 'if ($$_ =~ m/^tag:\s+nv_([\d\.]+)/) { print $$1 ; exit}')}" ; \
$(PERL) -p -e
"s{_PKGVERS_BUILD_}{$${PKGVERS_BUILD}};" \
# Set variables used by pkgmogrify # These are the macros that may be used in package manifests # Most upstream packages provide specific version numbers instead of using # the default of $(OSPKGVERS) # Some use $(X11PKGVERS) to refer to the X11 katamari version since they # bundle together components from multiple upstream packages with individual # Platform specific choices # Architecture specific directory names # Default transformations to apply # Extra transforms for non-legacy packages # Combine & uniq metadata & license attributes generated during build @
print "## Gathering metadata from build for $(@F)" @
print "## Processing manifest $(@F:.mog=.p5m)"# make the package lists from the real manifests for the synthetic manifests @
print "## Generating $(@F:packages.%=%) package list" -e
'if ($$_ =~ m{name=pkg.fmri value=(\S+)}) {' \
-e
' printf "depend fmri=$$1 type=\$$(PKGDEP_TYPE)\n";' \
# The package lists are generated with $(PKGDEP_TYPE) as their # dependency types, so that they can be included by either an # incorporation or a group package. # rule to build the synthetic manifests @
print "## Processing synthetic manifest $(@F:%.mog=%.p5m)" @
print "## Generating dependencies for $(<F)" @
print "## Skipping dependency generation for $(@F:%.dep=%)"### Dependency resolution # Root of pkg image to use for dependency resolution # Normally / on the machine used to build the binaries # This rule resolves dependencies across all manifests for packages # currently delivering files. print "## Suppressing dependency resolution"; \
print "## Resolving dependencies"; \
@
print "## Skipping dependency generation for $(@F:%.dep.res=%)"# Post-processing of manifests after dependency resolution ### pkglint checking (pre-publication) # This rule runs pkglint across all manifests to be published. # We require that packages be free from lint ERRORs before allowing them # to be published. Lint WARNINGs are acceptable (though unpleasant) # The list of packages is the list of packages that did not resolve to # 0-byte files, $CHECK_PKGS @
print "## Checking packages" if [[ -s $$
p.res ]];
then \
if [[ -n
"$${CHECK_PKGS}" ]];
then \
# Default in developer builds is "xnv-devel" # X RE cronjob build scripts override to "xnv-nightly" or "xnv-biweekly" # Initialize the empty on-disk repositories @
print "## Initializing $(@F)"### Package publication to repo print "## Publishing $(@F:%.pub=%) to proto repository"; \
@
print "## Creating repository metadata"### pkglint checking (post-publication) # Perform a pkglint run on the published repositories. We remove package # version information from the lint output so that it is comparable across @
print "## Running pkglint on the $(PKGPUBLISHER) repository"# rules to validate proto area against manifests, and check for safe # Automatically exclude all pkg-config uninstalled.pc files, since those # should never be packaged # Instead of fixing all the upstream packages to follow our permission rules # just fix the proto area to match our rules @
print "## Fixing proto area permissions"