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/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,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
