This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Generic build script instructions
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...
> : On Tue, 15 Jun 2004, Max Bowsher wrote:
> [...]
> : > This makes me wonder if it might be sensible for all package maintainers
> : > to say a little about their packaging methods, maybe even leading to a
> : > plan for a new standard cygwin package building system.
> [...]
> : I absolutely agree. If package maintainers could take some time to try to
> : adapt the CVS HEAD of the GBS
> : (<http://cygwin.com/cgi-bin/cvsweb.cgi/packaging/templates/generic-build-script?cvsroot=cygwin-apps&only_with_tag=HEAD>)
> : to their packages and let me (and this list, I guess) know what changes
> : needed to be made, we could try to extract common patterns and include
> : them into the CVS version.
>
> I am not a package maintainer, so EMBI.
I'm not familiar with the acronym. 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.
This doesn't mean that I won't be considering patches from
non-maintainers.
> 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.
> 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()"?
> : 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.
> : 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.
> : Igor
> : P.S. FWIW, another idea I had, akin to Max's python approach, was to
> : actually append a (wrapped) GBS patch to the GBS instead of changing the
> : script directly, and have the GBS detect that fact and apply the patch to
> : itself, then running the resulting script (piping it to an exec'ed shell).
> : Opinions?
>
> 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...
> [snip]
> BTW:
> 2004-02-18 Yaakov Selkowitz <yselk...
Thanks, fixed.
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