[csw-maintainers] Buildbot

Ben Walton bwalton at opencsw.org
Fri Jul 31 20:07:01 CEST 2009


Excerpts from Philip Brown's message of Fri Jul 31 12:47:57 -0400 2009:

> for example, if there were a flat namespace in the source tree, and if it
> were always possible to do

Part of the reason for the (admittedly) nasty directory structure is
subversion.  While we're following 'best'[1] practices for svn use by
having the {trunk,branches,tags}/ directory structure under each top
level package, it definitely makes the tree structure uglier.

The ability to checkout only a single part of the tree with svn is
it's only useful feature[2], I think.  This feature makes following the
three sub directory convention beneficial as tagging and branching can
be done more easily on a partial checkout[3]

> Define an absolute top-level "API" that doesnt require GAR, and you might
> see more stuff in there, even from the "GAR-o-phobes"
> Right now, you have sort of a defacto one from GAR usage. But you havent
> formally stated, "as long as you follow [this API], its ok even if you're
> not using gar]"

This is a good idea.  While I think GAR is good and it saves me lots
of time, we should promote a set of Make targets that all packages
support, even if they don't use GAR.  What should a Makefile
accomplish so that it's globally usable, say by a build bot system?

I'd say:

1. It must be able to retrieve it's own source tarball/repo/whatever,
   so the 'fetch' target should be honoured.
2. It must be able to apply patches supplied locally, so 'patch' is a
   must.
3. I'd then say both 'build' and 'package' should be individually
   callable steps.  A buildbot may only want to test that the updated
   commit can still successfully build the package while a release
   tool may need to be able to take things right up to the package
   files.
4. A 'clean' target is always a good thing to support.
5. A set of variables should be honoured by any Makefile such that a
   build system knows where to find outputs.

Moving to an API like this should promote more use of the global
repository while still making it usable for a global build/release
tool.  Are there other globally useful make targets I've overlooked?

Thoughts?
-Ben

[1] Putting best in a sentence with svn feels wrong.
[2] When comparing features offered by any modern SCM/VCS tool.
[3] This is my understanding.  Corrections welcome.
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090731/2f0b2af1/attachment-0002.asc>


More information about the maintainers mailing list