If you own a component in the SFW gate or plan on integrating one in the
future, read on and read carefully...
My recent integration of
6836557 sfw gate needs consistent metadata
introduces some change to the SFW gate.
* Each component now contains a METADATA file and that METADATA file
should contain a consistent set of fields with consistent values.
* The component builds will now validate that each component
contains a METADATA file and that the file contains what appears
to be valid data.
* All components' Makefile.sfw now indirectly include
$(SRC)/Makefile.targ, which defines sets of common rules. There
are currently rules defined for
o unpacking source for both 32 and 64 bit builds
o patching source for both 32 and 64 bit builds
o validating METADATA file contents
o hooks for other actions
* Two new top level targets have been introduced
o 'meta-check' to validate the METADATA files across all of
the components in the gate.
o 'component-hook' to perform a supplied action across each
component in the gate. (see example below)
If you attempt to build a component and it doesn't contain a METADATA
file or the validation tool determines it to be invalid in some way,
your build will fail. You must correct any ERROR reported by the
validation tool in order to proceed with your build.
If you own a component in the gate...
Please take the time to look at the METADATA file that currently
exists and verify it's accuracy. If the file doesn't contain
accurate information, please update it. A complete description of
the METADATA file contents can be found at
http://wikis.sun.com/display/SFWNotes/METADATA.
If you have a workspace that is waiting to integrate into the gate...
You must resync with the gate, add or update your METADATA file,
rebuild your component, and resolve any issues that show up. If you
don't, your integration will very likely break the gate.
A note about the OWNER field...
In the process of making these updates, I found the majority of the
OWNER information in the existing METADATA files was way out of
date. As a result, I have removed the OWNER field from the METADATA
and will be placing it in a table on the gate website, possibly out
on http://wikis.sun.com/display/SFWNotes/ as well. In the end, the
decision to remove the OWNER came down to the fact that staffing
changes shouldn't require a putback into the gate.
Example of checking a component's METADATA:
% cd {component-dir} ; make -f Makefile.sfw meta-check
Example of checking all components' METADATA:
% cd ${SRC}; make -f Makefile.sfw meta-check
Example of invoking 'component-hook' support:
% cd ${SRC} ; make COMPONENT_HOOK="cat METADATA" component-hook
One more bit of information about some changes on the horizon...
Over the next few weeks, I will be going through the various
components and unifying their unpacking and patching methodology
(hence some of the rules in $(SRC)/Makefile.targ). I will be
updating all of the unpacking and packing rules in the gate to use
the tools defined in Makefile.master and rules in Makefile.targ (at
least where possible). I will also be converting all patching that
I find to use unified context diffs that can be applied using "cd
$(@D) ; gpatch -p1 <.../foo.patch" during the patching phase of a
component build.
If you are integrating any new components into the gate over the
next few weeks, I would recommend that you take advantage of the
existing unpacking and patching rules already in the gate and that
any patches that you supply be unified context diffs that can be
applied via "cd $(@D) ; gpatch -p1 <.../foo.patch"
Unified Context Diffs can be generated using "diff -u" (see diff(1))
Ex:
% diff -u cups-1.4b2/backend/serial.c.orig
cups-1.4b2/backend/serial.c >> Patches/00-backend-serial.c.patch
-Norm
