This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Generic build script instructions
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