Re: Generic build script instructions

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

On Wed, 16 Jun 2004, Charles Wilson wrote:

> Igor Pechtchanski wrote:
>
> > P.S. FWIW, another idea I had, akin to Max's python approach, was to
> > actually append a (wrapped) GBS patch to the GBS instead of changing the
> > script directly, and have the GBS detect that fact and apply the patch to
> > itself, then running the resulting script (piping it to an exec'ed shell).
> > Opinions?
>
> I don't really like this -- it's moving more to a "standard tool +
> external configury" model, like imake (or even rpm/deb).  While that's
> not a BAD model, as obviously so many tools use it, it's not what gbs
> was originally intended to do.

I understand that gbs is really a template.  The above idea was actually
an add-on to help people who maintain multiple packages with gbs.
Alternatively, people will have to do a diff of gbs with the base version,
and then forward-port their changes if they want to move to a new version
(and there are reasons for this sometimes, e.g. switching to a different
FHS).

> Now, a change in direction is fine, if you're SURE that you want to go
> in that direction.  But consider, if you really want a standard tool +
> external configury model, if gbs is really the proper framework.
>
> I'd think that cgf's netrel (or several other build helpers mentioned on
> this list) would be a better fit for that model.  The extreme
> genericization(?) of gbs is only making the package more and more
> complicated -- and more daunting to a new porter just easing into cygwin
> maintainership.  It's no longer a simple, quick-n-dirty tool for making
> cygwin packages.
>
> Even dpkg/rpm + an "unroller" that turns the .rpm/.deb into a .tar.gz,
> and pulls the trigger-scripts out and puts them into /etc/*/
> appropriately, would be a better fit for the "standard tool + external
> configury" model than gbs, IMO.
>
> --
> Chuck

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.
But if you simply want to keep up with the gbs releases and features, and
keep some package-specific changes bundled up, isolating the patch seems
reasonable to me.  Mind you, this is for very simple patches, like
changing the type of the archive (e.g., one of my packages, jgraph, uses a
.shar.Z distribution), or changing the name of the makefile "test" rule...
I think anything complex enough to require a lot of changes will probably
not be using gbs anyway.
	Igor
P.S. And yes, I realize that anything that can be used can also be abused.
I'm willing to take that chance here.
-- 
				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