Generic build script instructions

[Igor Pechtchanski]

On Sat, 19 Jun 2004, Bas van Gompel wrote:

> Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski:
> :  On Sat, 19 Jun 2004, Bas van Gompel wrote:
> :
> : > Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski:
> : > :  On Fri, 18 Jun 2004, Bas van Gompel wrote:
> [<pechtcha at see es dot and why you dot ee dee you>]
> : > : Cute, very cute...
> : > Ehh... Thanks, I think.
> :
> :  Yeah, I just never saw this particular obfuscation before, is all. :-)
>
> I did it by hand. (I know, I should get a job.)

...hey, it was funny... :-)

> [EMBI]
> : > Excuse My Butting In.
> :
> :  Ok, this one's on its way to the OLOCA. :-D
> <g>

FWIW, it just got there.

> [package maintainers]
> : > I keep some packages locally, following changes are in them...
> :
> :  Then, as far as I'm concerned, you're a maintainer.  Any particular reason
> :  for not submitting those packages, though?  License issues, perhaps?
>
> 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...

> [...]
> : > The change in indentation makes the ``ispatch()'' call hard to spot,
> : > hence the (botched) copy.
> :
> :  Why not submit two separate patches, then? ;-)
>
> The change in indentation would still affect many lines which are not
> functionally changed. (I would thus want to add a 3rd patch.)

Umm, that's fine, you expect an indentation change when adding a while
loop.  I just didn't want to have another independent change sneak in
there unnoticed.  The multiple args patch has been committed, so the issue
is moot.

> [the purpose of "ispatch()"]
> : > In other words: ``ispatch'' copies the patch generated by ``mkpatch''
> : > from .sinst to ${topdir}, so it can be used now, not just get included
> : > by ``spkg''.
> :
> :  I see.  That's not quite the way I use the gbs (I never edit the patched
> :  directory, but keep the original edited version separately).
>
> ? I'm talking about when you first port the app, or when you are
> changing to a new upstream version.
>
> :    Perhaps
> :  "ispatch" is not the best name for it?
>
> Could be. You use it when you determine this _is_ the correct patch.
>
> :    Looks like "savepatch" might be
> :  better...  As I never intend to use this feature, the above is just a
> :  suggestion.
>
> I would expect that --``savepatch''-- to do st else (like store the
> patch from ${topdir} someplace). But if you insist I'll change it to
> that. I would prefer st different, though. (``acceptpatch'' maybe?)

As I said, these were suggestions.  "acceptpatch" sounds fine to me.
Unless anyone objects, we can go with that.

> : > : > : 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 saw a trick that might be usable for this somewhere... i'll get back
> : > : > to you on it...
> : > :
> : > :  I think we could use something like "make -n" and check the return code...
> : > :  But as I don't have the time to implement it properly now, I'll look at
> : > :  whatever methods people choose to provide in their patches.
> : >
> : > It was something using a ``make -f -'' IIRC... (l8r)
> :
> :  Hmm, "make -f -" will actually not be useful, FWICS.  We want to check
> :  whether the Makefile contains either a "test" or a "check" rule, whereas
> :  "make -f -" will bypass the Makefile altogether.  But if I'm wrong, it
> :  won't be the first time.
>
> 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.

> [snip]
> : > [append a (wrapped) GBS patch to the GBS]
> [store gbs, before mods to CYGWIN-PATCHES]
>
> :  Oh.  Well, again, I never store the build script into CYGWIN-PATCHES, but
> :  it doesn't mean that nobody else should...  Everyone has his own methods.
>
> I'm not saying anybody _should_, just that it will make upgrading the
> specific-build-script easier.
>
> : > Or maybe just store the diff? One could then recreate the original gbs
> : > to merge against.
> :
> :  That's more or less what I'm proposing.  Take the (default) gbs, add a
> :  section to it that does 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 && exec "$0"
> :
> :  and let the maintainers put their patches between the "cat" and
> :  "END-OF-PATCH".  At least, that's what I had in mind.  Then the set of
> :  changes to the gbs can be easily extracted (and moved) to the new version.
>
> Let me get this straight. First you take a copy of gbs. you edit it.
> You make a diff against the orig gbs. you paste that diff into yet
> another copy of the gbs. you then run the last one, which will then
> recreate the file you had before, by editing itself inplace? _Now_ I
> *am* 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...

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

This, IMO, creates a chicken-and-egg problem, as the patched directory
won't be available until the script is run...  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...
	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