Re: Generic build script instructions

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

On Tue, 15 Jun 2004, Max Bowsher wrote:

> Robb, Sam wrote:
> >>>   9) Generate a patch (./gbs mkpatch)
> >>>  10) Clean (./gbs mkpatch)
> >>
> >> should these both be mkpatch? ;)
> >
> > Hmm.  Perhaps that's my problem :-)
> >
> > The question still remains: assuming that I'm entering
> > the proper commands (instead of trying to clean using
> > "mkpatch" :-), is this more or less the way the gbs
> > is intended to be used?
>
> I'm not really sure how gbs is supposed to be used from a packager's POV.
> (The user's POV is obvious - ./gbs all)

I find it helpful to use the gbs to actually build the source and binary
packages (using "./gbs all").  When I'm debugging any build problems that
might arise, I'm also using the intermediate steps.  It really varies.

> I've found that its usually necessary to modify the gbs for each
> particular package. To try to maintain reasonable organization of these
> modifications, I'm piping the upstream gbs through a (fairly inelegant)
> python script, using per-package config files to specify certain sets of
> customizations.

It would be interesting to see exactly what changes need to be made to the
*current* GBS -- it's become much more "generic" than it used to be.

> This makes me wonder if it might be sensible for all package maintainers
> to say a little about their packaging methods, maybe even leading to a
> plan for a new standard cygwin package building system.
>
> Max.

I absolutely agree.  If package maintainers could take some time to try to
adapt the CVS HEAD of the GBS
(<http://cygwin.com/cgi-bin/cvsweb.cgi/packaging/templates/generic-build-script?cvsroot=cygwin-apps&only_with_tag=HEAD>)
to their packages and let me (and this list, I guess) know what changes
needed to be made, we could try to extract common patterns and include
them into the CVS version.  We could also try putting some more
autodetection code into the GBS (e.g., get "make" to try both the "test"
rule and the "check" rule -- the two most common names for running the
testsuite -- and pick the one that exists).

I'm willing to coordinate the effort on this, but please everyone feel
free to send patches based on the above input.  One major criterion for
accepting those patches would be to make the overall amount of changes to
the scripts smaller (with the secondary goal of making each individual set
of changes smaller).
	Igor
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?
-- 
				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