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 08:58:42 -0400 (EDT) schreef Igor Pechtchanski:
> : On Fri, 18 Jun 2004, Bas van Gompel wrote:
> :
> : > Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski
> : > <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. :-)
> [...package maintainers could take...adapt the CVS HEAD of the GBS...]
> : > I am not a package maintainer, so EMBI.
> : I'm not familiar with the acronym.
> Excuse My Butting In.
Ok, this one's on its way to the OLOCA. :-D
> : What I meant by "package maintainers
> : take time to adapt the CVS head of the GBS" was that most packages now use
> : an older version of the GBS, and don't keep the CVS Id, so that makes it
> : very hard to determine the exact set of changes that everyone had to make.
>
> 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?
> : This doesn't mean that I won't be considering patches from
> : non-maintainers.
>
> Pfew!
See above. :-)
> : > Following are two patches, one (inline) for review (ignoring
> : > changes in whitespace) and one (attached) for easy application
> : > (``patch <gbs-loop-ispatch.patch'' in the src-directory.)
> :
> : FWIW, I can review attached patches just as easily as the inline ones --
> : no need to duplicate the information.
>
> The change in indentation makes the ``ispatch()'' call hard to spot,
> hence the (botched) copy.
Why not submit two separate patches, then? ;-)
> : > Each of them does:
> : >
> : > *) Allow more than one argument at a time (e.g. do
> : > ``./boffo-1.0.36-1.sh prep conf build'').
> : >
> : > *) An ``ispatch'' command, copying a fresh patch, to make the porting
> : > process easier. (When you're done editing, do a
> : > ``./boffo-1.0.36-1 clean mkpatch ispatch finish all''
> : > to get your new packages.) It backs up your old patch, to be on the
> : > safe side.
> :
> : I'm not clear on what the second part does. Could you please elaborate on
> : the purpose of "ispatch()"?
>
> Ok. Let me try to make this clear...
>
> You install the upstream package and a new gbs. you do a
> ``./boffo-x.y-1.sh prep'', cd into boffo-x.y and edit some files.
> You now do a ``./boffo-x.y-1.sh conf build'' and discover the
> build succeeds. A ``./boffo-x.y-1.sh check'' reveals it passes it's
> testsuite. You do a ``./boffo-x.y-1.sh clean mkpatch'' and
> look at the generated patch. It looks OK. You can then do
> `./boffo-x.y-1.sh ispatch'' to make sure you don't lose your
> edits when you remove the boffo-x.y-directory (e.g. by doing
> `./boffo-x.y-1.sh finish all'').
>
> 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). Perhaps
"ispatch" is not the best name for it? Looks like "savepatch" might be
better... As I never intend to use this feature, the above is just a
suggestion.
> : > : 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.
> : > : I'm willing to coordinate the effort on this, but please everyone feel
> : > : free to send patches based on the above input. One major criterion for
> : > : accepting those patches would be to make the overall amount of changes to
> : > : the scripts smaller (with the secondary goal of making each individual set
> : > : of changes smaller).
> : >
> : > Should not the main objective be to make the needed effort (for
> : > understanding, maintaining, using effectively) smallest? (NRN)
> :
> : Well, not quite. The main objective, as far as I understood Chuck
> : Wilson's comments, was to be able to get a *new* package off the ground
> : fast. The GBS embodies several of the policies (e.g., the FHS, the
> : default configure arguments, the tarball filenames) which would otherwise
> : need to be taken care of. The more packages can be built with a minimal
> : (preferably empty) set of changes, the better. Understandability is
> : certainly an issue. Judging the needed effort, however, is very
> : subjective, so I'd prefer using the size of the necessary patch to
> : quantify it.
>
> Fair enough. Ny point was: Allowing multiple arguments, or auto-
> detecting various aspects, makes the patches bigger, but the gbs
> more useful.
Oh, I see the confusion. I didn't mean the size of the patches that are
incorporated into the gbs itself -- those can be arbitrarily large. I
meant the size of the patches that the packagers have to maintain
separately from the gbs, i.e., the things in the package build that don't
fit into the gbs defaults. I think it's pretty obvious that *those*
should be small.
> [append a (wrapped) GBS patch to the GBS]
>
> : > Would not that create an entirely new build method (with a very
> : > impractical structure)?
> : >
> : > Isn't it more in style with method 2 to store a copy of the gbs,
> : > before you made any mods to it, in CYGWIN-PATCHES? you can then
> : > always (diff out any changes you made/merge in changes from the
> : > latest cvs version).
> :
> : Huh? No, the GBS just gets edited -- I don't think it should go into
> : CYGWIN-PATCHES...
>
> It improves maintainability e.g.
> ``diff -u boffo-x.y/CYGWIN-PATCHES/gbs-orig boffo-x.y-1.sh''
> and
> ``merge boffo-x.y-1.sh boffo-x.y/CYGWIN-PATCHES/gbs-orig cvsdir/gbs-new
> cp cvsdir/gbs-new boffo-x.y/CYGWIN-PATCHES/gbs-orig''
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.
> 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.
Hope this clears up the confusion,
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