This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch] g-b-s: New command: upgrade-self. (was: Re: generic-build-script extension to update version numbers in README)

Op Fri, 18 Nov 2005 23:20:25 -0500 schreef Charles Wilson
in <437EA809.30204<at>>:
:  Igor Pechtchanski wrote:
[new gbs features]

:  Well, the problem is, logging is a decorator: it decorates the existing 
:  functions.  Unless you want a whole new build-with-logging() function 
:  that has to be maintained in parallel with the regular build() function 
:  for package foo, I don't see how this particular feature can be moved 
:  out of the core gbs without getting REAL ugly: building cmd strings, 
:  possibly decorating _those_, and then eval'ing them.  Sad, really.

How about:
build_with_logging() {
  build 2>&1 |tee <logfilename>

: >> Every new feature added to gbs makes it that much more difficult for
: >> maintainers to keep pace with gbs updates when they update their
: >> packages. Please think carefully before adding new stuff: is feature X
: >> *really* worth it?

So, I'm gonna suggest another feature. >:->

: > BTW, thanks for your comments, Chuck.  I'm afraid I lost sight of the fact
: > that many maintainers have private mods to the g-b-s, and that feature
: > updates may cause them trouble.  We should definitely rectify this.

:  The problem comes in when trying to 'upgrade' our fork to the ongoing 
:  development in the 'trunk'.  It really is a branch-and-merge-from type 
:  of operation.  Maybe I should give that local cvs mirror idea some more 
:  thought...

I came up with the following, which should make upgrading easier in
the future. You'll still have to hand-merge this into your existing
scripts though, sorry, but from then on, non-conflicting updates to
g-b-s should be easily retrieved.

How it works: When invoked with the `upgrade-self' command, the script
attempts to get the HEAD-version from cvs, if it hasn't in the last
24 hours. This HEAD-version is invoked with the `version' command
to get it's CVS-revision. If it was just downloaded, the HEAD revision
is stored in /usr/share/gbs as generic-build-script-HEAD and
generic-build-script-<HEAD-revision> If the HEAD-revision doesn't
match this build-script's CVS-revision, the build-script's revision
is gotten from /usr/share/gbs if available, otherwise it is gotten
through CVS and stored in /usr/share/gbs. Than merging is done
on a copy of the build-script. If the merge has conflicts, one is
given the possibility to edit the script and the option to reject the
new script. Finally the new script is copied into place and executed
with the remaining parameters.

ChangeLog-entry: (Please fix the <at>.)

2005-11-21  Bas van Gompel  <<at>>

	* templates/generic-build-script Add upgrade-self to main switch.
	(help): Add upgrade_self.
	(upgrade_self): new function.


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

Attachment: gbs-update-self.patch
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]