Re: Generic build script instructions

[Bas van Gompel <cygwin-apps dot buzz at bavag dot tmfweb dot nl>]

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