This is the mail archive of the
mailing list for the cygwin project.
Re: generic-build-script extension to update version numbers in README
- From: "Gerrit P. Haase" <gerrit at familiehaase dot de>
- To: "CygTalk" <cygwin-talk at cygwin dot com>
- Date: Sun, 20 Nov 2005 02:37:00 +0100
- Subject: Re: generic-build-script extension to update version numbers in README
- References: <437E4CD3.email@example.com> <437E7606.firstname.lastname@example.org> <Pine.GSO.email@example.com> <437F3A70.firstname.lastname@example.org> <437F71E8.email@example.com>
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
Max Bowsher wrote:
Christian Franke wrote:
What would you think about an autoconf-like approach generating a
"package-VER.sh" script from some "package.sh.in" (yes, no version).
It is a good idea, but I would avoid .in naming, since I think we will
want to go beyond simple autoconf-style variable substitution.
I'm already doing programmatic editing of the g-b-s for my own packages.
Attached is 'gbsmunge.py', which reads a control file, and the
generic-build-script source, and outputs a build script munged according
to instructions in the control file.
For illustrative purposes, here is the control file for my neon package:
SubPackage libneon24-$VER-$REL.tar.bz2 usr/bin/cygneon-24.dll
Hey you guys, you're going to recreate whole package build management
systems like debian has it, or gentoo, or even slackware. What about
a GUI for this? Maybe based on Qt, so at least maintainers are forced
to install and use at least 90% of all Cygwin packages which would
increase usability over the years.