build system glue scripts and requirements

[Ville Skyttä]

On Sun, 2005-03-20 at 10:06 -0500, seth vidal wrote:
> > I think requiring a tag of some kind in CVS to trigger a build would be
> > cool: it ensures that builds are actually tagged.
> > 
> > Maybe something like this:
> > "make tag" in a CVS checkout could do the tagging with the appropriate
> > tag name derived from the package (N?)EVR(+branch?), as well as force-
> > tag a special transient and moving BUILDME_DAMMIT'ish tag which the
> > buildsys could look for.  However, the buildsys needs to be able to
> > figure out when to build based on new tags appearing in CVS or existing
> > tags being moved to new revisions.  That might be a bit tricky, but I
> > think it's doable.  Or there could be a special BUILDIT'ish file
> > (possibly GPG signed) committed to CVS containing checksums of some kind
> > and the tag to build.
> 
> problem: what if you only want a single arch built, how do you specify a
> single arch be built via the tag? How do you deal with test non-release
> builds? That's my concern about tag-based building, it seems kinda
> limited.
> 
> I'd think having tagged releases + some way of instructing the
> buildsystem that we want it built 1. for release 2. for a set of archs,
> would probably give us more flexibility.

The second "special file" approach could be used for this, although
there might be better and more user friendly approaches.  Anyway, eg.
something like this (disclaimer: unfiltered raw braindump):

  echo 'tag archs buildtype' \
  | gpg --clearsign > BUILD && cvs ci -m 'Build request' BUILD

  (Yes, I'm aware that this doesn't contain enough uniquely identifying
   data so that it would make sense to sign it, think replayability 
   elsewhere in the CVS repo.  But don't get stuck wit that now :)

  Synopsis:
     tag [archs [buildtype]]

  tag:
    The tag to build.
  archs (optional):
    The archs to build for, ALL (or not present) means all supported.
  buildtype (optional):
    Type of build, enumeration of keywords.  "release" or not present
    means a release build, add others as needed.

The buildsys could either "cvs up" and/or "cvs stat" all BUILD files, or
be configured to receive notifications from the CVS server some way when
they are changed, eg. mail.

Semi-offtopic: it would be good to prepare the infrastructure so that
rpmbuild args could be passed to the build system some way.  One example
of potential packages that could benefit from this would be kernel
module packages where the module specfiles wouldn't need changes between
target kernel revisions, instead the target kernel(s) to build for would
be identified by eg. a --define to rpmbuild.