This is the mail archive of the cygwin-apps@cygwin.com 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]

Re: Generic build script instructions


Igor Pechtchanski wrote:

P.S. FWIW, another idea I had, akin to Max's python approach, was to
actually append a (wrapped) GBS patch to the GBS instead of changing the
script directly, and have the GBS detect that fact and apply the patch to
itself, then running the resulting script (piping it to an exec'ed shell).
Opinions?

I don't really like this -- it's moving more to a "standard tool + external configury" model, like imake (or even rpm/deb). While that's not a BAD model, as obviously so many tools use it, it's not what gbs was originally intended to do.


Now, a change in direction is fine, if you're SURE that you want to go in that direction. But consider, if you really want a standard tool + external configury model, if gbs is really the proper framework.

I'd think that cgf's netrel (or several other build helpers mentioned on this list) would be a better fit for that model. The extreme genericization(?) of gbs is only making the package more and more complicated -- and more daunting to a new porter just easing into cygwin maintainership. It's no longer a simple, quick-n-dirty tool for making cygwin packages.

Even dpkg/rpm + an "unroller" that turns the .rpm/.deb into a .tar.gz, and pulls the trigger-scripts out and puts them into /etc/*/ appropriately, would be a better fit for the "standard tool + external configury" model than gbs, IMO.

--
Chuck


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