Generic build script instructions

Bas van Gompel
Sat Jun 19 00:17:00 GMT 2004

Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski in
:  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.

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

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

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

The change in indentation makes the ``ispatch()'' call hard to spot,
hence the (botched) copy.

: > Each of them does:
: >
: > *) Allow more than one argument at a time (e.g. do
: > ``./ 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
``./ prep'', cd into boffo-x.y and edit some files.
You now do a ``./ conf build'' and discover the
build succeeds. A ``./ check'' reveals it passes it's
testsuite. You do a ``./ clean mkpatch'' and
look at the generated patch. It looks OK. You can then do
`./ ispatch'' to make sure you don't lose your
edits when you remove the boffo-x.y-directory (e.g. by doing
`./ 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''.

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

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

[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

It improves maintainability e.g.
``diff -u  boffo-x.y/CYGWIN-PATCHES/gbs-orig''
``merge boffo-x.y/CYGWIN-PATCHES/gbs-orig cvsdir/gbs-new
cp cvsdir/gbs-new boffo-x.y/CYGWIN-PATCHES/gbs-orig''

Or maybe just store the diff? One could then recreate the original gbs
to merge against.



  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\"    | me. 4^re

More information about the Cygwin-apps mailing list