Generic build script instructions

Robb, Sam
Thu Jun 17 04:32:00 GMT 2004

> Well, yes, I agree that if you really anticipate having to maintain
> multiple packages from the outset, and want to keep more or less the same
> build procedure for each of them (helps if they are related), you should
> probably start already with something more sophisticated than the gbs.

I don't know.  The gbs seems to be pretty good at accomplishing
it's goals without introducing a whole lot of extra overhead;
the main problem would seem to be that there's really no way
to customize the script without altering it.

So, to answer that question, why not something like this:

  # --- BEGIN_DEFS ---
  if [ -f ${FULLPKG}.defs ]; then
    . ${FULLPKG}.defs
  # --- END_DEFS ---

So, if my source package name is foo.tar.Z, then I can put the
following in my defs file:

  # Maintainer defs file for package foo

This would allow a package maintainer to put specializatons/
definitions within a defs file for each package, making for
easier maintentance (except in cases of siginificantly unusual

Next, modify the gbs so that the version of the gbs that
gets included as part of the source package is result of
merging the defs file and the canonical gbs.  In the above
example, when the maintainer built the source package,
everything in between the BEGIN_DEFS and the END_DEFS lines
would be replaced with the actual contents of the maintainer's
def file for the package, so that the packaged gbs would
actually look like the following:

  # --- BEGIN_DEFS ---
  # --- END_DEFS ---

For this to really be effective, you'd have to have the ability
to override more than just the source package name and the
decompression flags :-/

You could probably get fancy, and do things like allow the defs
file to override individual functions (ie, unpack() checks to
see if defs_unpack() is defined; if it is, it calls defs_unpack(),
otherwise it calls std_unpack(), etc.)


More information about the Cygwin-apps mailing list