This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski in <Pine.GSO.4.58.0406191526380.3356@slinky.cs.nyu.edu>: : On Sat, 19 Jun 2004, Bas van Gompel wrote: : : > Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski: ...Snipped some stuff that was going OT, enjoyable though it was... [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? [why not 2 patches] : is moot. Right. ;) ["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}. [autodetect testsuite rule] : > Found it. it uses ``-f Makefile -f -'' to get the value of : > a Makefile-variable, and is of no use to us here. ``make -n'' : > is probably the WTG. : : Okay, we'll see what can be done. Yes, we will. :) : > [snip] [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.) : > : 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? L8r,
Attachment:
gbs-acceptpatch.patch
Description: Text document
Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | / / really is | and false bits entirely. | post for ) | | / / a 72 by 4 +-------------------------------+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |