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] |
Op Fri, 18 Nov 2005 23:20:25 -0500 schreef Charles Wilson in <437EA809.30204<at>cwilson.fastmail.fm>: : 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 <g-b-s-patch.buzz<at>bavag.tmfweb.nl> * templates/generic-build-script Add upgrade-self to main switch. (help): Add upgrade_self. (upgrade_self): new function. L8r, Buzz. -- ) | | ---/ ---/ 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)\1.as." | 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] |