This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Generic build script instructions
On Sun, 20 Jun 2004, Bas van Gompel wrote:
> Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski:
> : On Sat, 19 Jun 2004, Bas van Gompel wrote:
> :
> : > Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski:
>
> [reason for not submitting packages?]
> : > One, (s-lang) is rather complex and I expect I could not really
> : > support it. It also builds OOTB (sort of). (I'll consider votes an
> : > incentive to start cleaning up my patches >:-> ). The other is just
> : > waiting for the announced maintainer to publish his work. (core-utils)
> :
> : Oh. Well, if nothing else, it's a valuable experience for you...
>
> What is? Are you suggesting I ITP s-lang?
It = keeping a local copy. I'm very much against pressuring anyone into
ITP'ing anything... :-)
> ["ispatch" is not the best name]
> ["savepatch", ``acceptpatch'')
> :
> : As I said, these were suggestions. "acceptpatch" sounds fine to me.
> : Unless anyone objects, we can go with that.
>
> I'm attaching the patch.
>
> ChangeLog entry:
>
> 2004-06-20 Bas van Gompel <g-b-s-patch.buzz@bavag.tmfweb.nl>
>
> * templates/generic-build-script (acceptpatch): New function to copy
> a fresh patch from ${srcinstdir} to ${topdir}.
Looks good. Any objections from people to me checking this in?
> [Igor: append a (wrapped) GBS patch to the GBS]
> [Buzz: store gbs, before mods to CYGWIN-PATCHES]
> [Igor: gbs patching self in place]
> [Buzz: confused]
>
> : Umm, on reviewing it in light of morning (it was late night when I wrote
> : the above yesterday), it does look nonsensical. I probably meant
> : something like
> :
> : (echo "--- generic-build-script
> : +++ $0"; cat <<END-OF-PATCH
> : @@ -1,100 +1,100 @@
> : - patch goes here
> : + patch goes here
> : END-OF-PATCH
> : ) | patch -o tmp.$$.sh && exec tmp.$$.sh
> :
> : instead. This certainly makes more sense...
>
> I still wonder why you'd would want to do this. If you must have the
> ``state'' stored in the same file, why not store the diff in a copy
> of the _modified_ gbs, not the original. You would then not have to
> patch the script for every run. (You'd _still_ have to jump through
> several burning hoops to edit the resulting build-script, while
> keeping the diff current, though.)
The rationale for doing it the way I suggested is that forward-porting the
changes will usually involve simply copying the patch part into the new
gbs version, where it might apply with some fuzz. However, this will not
always work, and will only postpone the inevitable... Come to think of
it, it might just be easier to do an equivalent of "cvs diff -rBASE
-rHEAD", and apply that (after suitable modification) to the package build
script. Oh, well...
> : > : Hope this clears up the confusion,
> : >
> : > I think storing the diff in CYGWIN-PATCHES (and having it automatically
> : > be included in foo-x.y-z.patch) is cleanest/clearest.
>
> I'm not sure about this anymore. Probably storing the orig gbs /is/
> easier/less error-prone.
>
> : This, IMO, creates a chicken-and-egg problem, as the patched directory
> : won't be available until the script is run...
>
> Not really. Just keep a copy of the unedited gbs in topdir until you
> round off your changes and get ready to do a ``spkg''. At that time
> store the diff (or gbs-orig) into C-P. (Just remember to recreate the
> original gbs before later editing the modified one, if storing the
> diff.)
>
> : Also, foo-x.y-z.patch
> : usually stores the diff between the original source and the Cygwin package
> : source, and the original won't have contained the unpatched gbs...
>
> The original source won't have contained a generic-readme either...
> There is a reason the directory is called CYGWIN-PATCHES, isn't there?
Yep, you got a point. What I meant, however, is that since the original
will have contained neither the gbs nor the generic-readme, they will have
to be *added* to CYGWIN-PATCHES, which will make any package-specific
changes in them to not appear in the patch...
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