() [EMAIL PROTECTED] (Ludovic Courtès) () Wed, 16 Jul 2008 15:21:48 +0200 I've never actually used that option, but can you provide rationale for removing it? I'd rather not remove it without a good reason to do so.
It's not useful (you said it yourself). I bet that if we were to omit the removal of this misfeature from NEWS, no one would even notice. (Same goes for --guileversion and --help-all, which are next up on the chopping block.) For a preview of where i imagine official Guile's guile-tools should go (not far), please find attached the Guile 1.4.1.118 variant. In terms of (re-)design rationale, the idea is to move away from gratuitous variability: [It was (sort of) nice that guile-tools could be used to mux (dispatch) other functionality, but that sort of flexibility is available by more standard means (e.g., set PATH env var).] and towards reliable reflection: [Many programs dispatched by guile-tools useful for maintaining packages (config/build/install) have an invocation context of either the configure script (produced by autoconf) or a makefile (possibly, but not always, produced by automake). So, it's a good idea to mesh well w/ the autoconf spirit of probing features (instead of simply version numbers).] I hope this explains the thought behind the 1.4.1.118 guile-tools, which is the basis for this set of proposed (and to be proposed) changes. You can see the 1.4.1.118 guile-tools in action in Guile-PG's configure.in (unreleased, see <http://www.gnuvola.org/wip/>), lines 51 and 52, for example. thi ________________________________________________________________
guile-tools.in
Description: Binary data
