RE: Generic build script instructions

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 17 Jun 2004, Robb, Sam wrote:

> > 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
>   fi
>   # --- 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
>   src_orig_pkg_name=foo.tar.Z
>   opt_decomp=z
>
> 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
> packages).
>
> 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 ---
>   src_orig_pkg_name=foo.tar.Z
>   opt_decomp=z
>   # --- 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.)

Well, that was essentially the idea that started this thread, except that
I was thinking of (a) always embedding the .defs file at the end of the
package-specific build script (b) as a patch.  I tried to get the gbs to
the state where for most purposes one would just need to change a few
variables / override a function or two, and let the gbs do its magic.
Perhaps instead of a patch we could define a setup() function that will
initially be empty, and have the maintainers redefine it.  Then all the
standard values will be assigned only if the variables weren't already
defined by the setup() function.

FWIW, I don't think Gary's right on croaking if there's no .defs file --
for some (most?) packages, the gbs is fine as is, and we can always assume
a missing .defs file the same as an empty one (i.e., accept the defaults).
This is especially true if one adopts an "empty default setup()" approach.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton