Makefile revision d2aad38f82a2b5085cc6ee00170dcd255c2b5ef7
# pass PKGMACH=$(PKGMACH) explicitly on the command line. If # this is done incorrectly, then packaging will fail, and you # will see the value of $(uname -p) instead of the value of # $(PKGMACH) in the commands that fail. # Refer also to the convenience targets defined later in this # ROOT, TOOLS_PROTO, and PKGARCHIVE should be set by nightly or # bldenv. These macros translate them into terms of $PKGMACH, instead # The publish transforms, EXCEPTIONS list, and some manifests need to # know when we're building open-only and when we're using internal # We only use internal crypto when we're doing a closed build, the # CODESIGN_USER env variable is not set, and ON_CRYPTO_BINS is not set. # This matches the conditions under which the internal key and cert # are needed for the packaged objects. # We use X_FLAG, as exported by nightly and bldenv, to decide when we # need IHV-related exceptions for protocmp. # Always build the redistributable repository, but only build the # nonredistributable bits if we have access to closed source. # Some objects that result from the closed build are still # redistributable, and should be packaged as part of an open-only # build. Access to those objects is provided via the closed-bins # The packages directory will contain the processed manifests as # direct build targets and subdirectories for package metadata extracted # incidentally during manifest processing. # Nothing underneath $(PDIR) should ever be managed by SCM. # The tools proto must be specified for dependency generation. # Publication from the tools proto area is managed in the # To get these defaults, manifests should simply refer to $(PKGVERS). # The ARCH32 and ARCH64 macros are used in the manifests to express # architecture-specific subdirectories in the installation paths # for isaexec'd commands. # We can't simply use $(MACH32) and $(MACH64) here, because they're # only defined for the build architecture. To do cross-platform # packaging, we need both values. # macros and transforms needed by pkgmogrify # If you append to this list using target-specific assignments (:=), # be very careful that the targets are of the form $(PDIR)/pkgname. If # you use a higher level target, or a package list, you'll trigger a # complete reprocessing of all manifests because they'll fail command # 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. # All packaging build products should go into $(PDIR), so they don't # need to be included separately in CLOBBERFILES. # By default, PKGS will list all manifests. To build and/or publish a # subset of packages, override this on the command line or in the # build environment and then reference (implicitly or explicitly) the all # Track the synthetic manifests separately so we can properly express # build rules and dependencies. The synthetic and real packages use # different sets of transforms and macros for pkgmogrify. # For each package, we determine the target repository based on # manifest-embedded metadata. Because we make that determination on # the fly, the publication target cannot be expressed as a # subdirectory inside the unknown-by-the-makefile target repository. # In order to limit the target set to real files in known locations, # we use a ".pub" file in $(PDIR) for each processed manifest, regardless # of content or target repository. # Any given repository- and status-specific package list may be empty, # but we can only determine that dynamically, so we always generate all # lists for each repository we're building. # The meanings of each package status are as follows: # ---------- ---------------------------------------------------- # noincorp Do not include in incorporation or group package # obsolete Include in incorporation, but not group package # renamed Include in incorporation, but not group package # current Include in incorporation and group package # Since the semantics of the "noincorp" package status dictate that # such packages are not included in the incorporation or group packages, # there is no need to build noincorp package lists. # For a single manifest, the dependency chain looks like this: # | use pkgmogrify to process raw manifest # * | use pkgdepend generate to generate dependencies # % | use pkgdepend resolve to resolve dependencies # manifest with dependencies resolved (mypkg.res) # | use pkgsend to publish the package # placeholder to indicate successful publication (mypkg.pub) # * This may be suppressed via SUPPRESSPKGDEP. The resulting # packages will install correctly, but care must be taken to # install all dependencies, because pkg will not have the input # it needs to determine this automatically. # % This is included in this diagram to make the picture complete, but # this is a point of synchronization in the build process. # Dependency resolution is actually done once on the entire set of # manifests, not on a per-package basis. # The full dependency chain for generating everything that needs to be # published, without actually publishing it, looks like this: # processed synthetic packages # package lists synthetic package manifests # processed real packages # package dir real package manifests # Here, each item is a set of real or synthetic packages. For this # portion of the build, no reference is made to the proto area. It is # therefore suitable for the "all" target, as opposed to "install." # Since each of these steps is expressed explicitly, "all" need only # depend on the head of the chain. # From the end of manifest processing, the publication dependency # repository metadata (catalogs and search indices) # repositories resolved dependencies # pkgsend | | pkgdepend resolve # | generated dependencies # Due to limitations in pkgdepend, we cannot simply treat synthetic # and real manifests identically. But we don't really want to # maintain a separate chain for synthetic manifests, so for the left # side of this diagram, we actually do faux dependency generation and # resolution, so we end up with the expected set of files in $(PDIR), # per the individual file chain described above: mf, mog, dep, res, # and pub files for each manifest. # This will build the directory to contain the processed manifests # and the metadata symlinks. # This rule resolves dependencies across all published manifests. # We should be able to do this with # pkgdepend resolve -m $(PUB_PKGS:%.pub=%.dep) # but until 14113 is fixed, the incorporations confuse pkgdepend, so we # just create the .res file for DEP_SYNTH_PKGS directly. # We also shouldn't have to ignore the error from pkgdepend, but # until at least 14110 is resolved, pkgdepend will always exit with print "Suppressing dependency resolution"; \
print "Resolving dependencies"; \
print "Removing dependency versions from $$p"; \
@
print "Creating repository metadata"# Since we create zero-length processed manifests for a graceful abort # from pkgmogrify, we need to detect that here and make no effort to # For all other packages, we publish them regardless of status. We # derive the target repository as a component of the metadata-derived # symlink for each package. # Initialize the empty on-disk repositories @
print "Initializing $(@F)"# rule to process real manifests # To allow redistributability and package status to change, we must # remove not only the actual build target (the processed manifest), but # also the incidental ones (the metadata-derived symlinks). # If pkgmogrify exits cleanly but fails to create the specified output # file, it means that it encountered an abort directive. That means # that this package should not be published for this particular build # environment. Since we can't prune such packages from $(PKGS) # retroactively, we need to create an empty target file to keep make # from trying to rebuild it every time. For these empty targets, we # do not create metadata symlinks. # Automatic dependency resolution to files is also done at this phase of # processing. The skipped packages are skipped due to existing bugs # The incorporation dependency is tricky: it needs to go into all # current and renamed manifests (ie all incorporated packages), but we # don't know which those are until after we run pkgmogrify. So # instead of expressing it as a transform, we tack it on ex post facto. # - The first $(RM) must not match other manifests, or we'll run into # race conditions with parallel manifest processing. # - The make macros [ie $(MACRO)] are evaluated when the makefile is # read in, and will result in a fixed, macro-expanded rule for each # target enumerated in $(PROC_PKGS). # - The shell variables (ie $$VAR) are assigned on the fly, as the rule # is executed. The results may only be referenced in the shell in # which they are assigned, so from the perspective of make, all code # that needs these variables needs to be part of the same line of # code. Hence the use of command separators and line continuation # - The extract_metadata transforms are designed to spit out shell # variable assignments to stdout. Those are published to the # .vars temporary files, and then used as input to the eval # statement. This is done in stages specifically so that pkgmogrify # can signal failure if the manifest has a syntactic or other error. # The eval statement should begin with the default values, and the # output from pkgmogrify (if any) should be in the form of a # variable assignment to override those defaults. # - When this rule completes execution, it must leave an updated # target file ($@) in place, or make will reprocess the package # every time it encounters it as a dependency. Hence the "touch" # statement to ensure that the target is created, even when # pkgmogrify encounters an abort in the publish transforms. This # will not cause publication failures when switching build # environments, because $(CLOSED_BUILD) and $(OPEN_ONLY) are # referenced in $(PKGMOG_DEFINES), and changes will therefore # trigger a rebuild for command dependency failure. (Command # dependency checking is turned on by .KEEP_STATE: above.) @
print "Processing manifest $(<F)" @
print "Generating dependencies for $(<F)"# The full chain implies that there should be a .dep.res suffix rule, # but dependency generation is done on a set of manifests, rather than # on a per-manifest basis. Instead, see the gendeps rule above. r=$${m
#$(@F:%.pub=%.metadata.)+(?).}; \ print "Publishing $(@F:%.pub=%) to $$r repository"; \
# rule to build the synthetic manifests # This rule necessarily has PKGDEP_TYPE that changes according to # the specific synthetic manifest. Rather than escape command # dependency checking for the real manifest processing, or failing to # express the (indirect) dependency of synthetic manifests on real # manifests, we simply split this rule out from the one above. # The implementation notes from the previous rule are applicable @
print "Processing synthetic manifest $(@F:%.mog=%.mf)" @
print "Skipping dependency generation for $(@F:%.dep=%)"# This rule assumes that all links in the $PKGSTAT directories # point to valid manifests, and will fail the make run if one # does not contain an fmri. # We do this in the BEGIN action instead of using pattern matching # because we expect the fmri to be at or near the first line of each input # file, and this way lets us avoid reading the rest of the file after we # We keep track of a failure to locate an fmri, so we can fail the # make run, but we still attempt to process each package in the # additional useful info. # The protolist is used for bfu archive creation, which may be invoked # interactively by the user. Both protolist and PKGLISTS targets # depend on $(PROC_PKGS), but protolist builds them recursively. # To avoid collisions, we insert protolist into the dependency chain # here. This has two somewhat subtle benefits: it allows bfu archive # creation to work correctly, even when -a was not part of NIGHTLY_OPTIONS, # and it ensures that a protolist file here will always correspond to the # contents of the processed manifests, which can vary depending on build print "Generating $$r $$s package list"; \
for (i = 1; i < ARGC; i++) { \ e = getline f < ARGV[i]; \ } while ((e == 1) && (f !~ /name=pkg.fmri/)); \ print "depend fmri=" a[l], \ "type=$$(PKGDEP_TYPE)"; \ print "no fmri in " ARGV[i] >> "/dev/stderr"; \ # rules to validate proto area against manifests, check for safe # file permission modes, and generate a faux proto list # For the check targets, the dependencies on $(PROC_PKGS) is specified # as a subordinate make process in order to suppress output. # This is a convenience target to allow package names to function as # build targets. Generally, using it is only useful when iterating on # development of a manifest. # When processing a manifest, use the basename (without extension) of # the package. When publishing, use the basename with a ".pub" # Other than during manifest development, the preferred usage is to # avoid these targets and override PKGS on the make command line and # use the provided all and install targets. # This is a convenience target to resolve dependencies without publishing # These are convenience targets for cross-platform packaging. If you # want to build any of "the normal" targets for a different # architecture, simply use "arch/target" as your build target. # Since the most common use case for this is "install," the architecture # specific install targets have been further abbreviated to elide "/install." $(SED) -e
"/^# EXPORT DELETE START/,/^# EXPORT DELETE END/d" \
$(SED) -e
"/^# CRYPT DELETE START/,/^# CRYPT DELETE END/d" \