This is the mail archive of the 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]

Re: Generic build script instructions

Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski
in <>:
:  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  <>

	* 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
:  ) | 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

:    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?


Attachment: gbs-acceptpatch.patch
Description: Text document

  ) |  | ---/ ---/  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)\"    | me. 4^re

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]