generic-build-script extension to update version numbers in README
Sat Nov 19 14:45:00 GMT 2005
Igor Pechtchanski wrote:
>>P.S. It'd be a different story if we were using an 'engine' with
>>external overrides, like mingwports or cgf's netrel(?) -- then mods to
>>the engine to provide new features would be distinct from the
>>package-specific overrides. But gbs ain't like that.
>What's stopping us from trying to get there? Anything specific to the
>nature of the g-b-s? One way to address this may be defining more
>functions like "unpack()" to contain the pluggable/overridable behavior.
What would you think about an autoconf-like approach generating a
"package-VER.sh" script from some "package.sh.in" (yes, no version).
Then fixes and new features will be added to only one generation tool
(autogbs ?-)) which can be part of a standard Cygwin package managed by
The generator can check the actual structure of the source tree to
create a smaller build-script.
New features can be opt'ed in by directives in the package.sh.in script
Like with autoconf, it would be possibled to do special hacks by
including shell code verbatim.
The package-sh.in can be put in the CVS of maintainer or be part of
projects sourcecode (e.g. as some Cygwin-build-script.sh.in)
More information about the Cygwin-apps