[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updating guile-tools: no more --scriptsdir

From: Thien-Thi Nguyen
Subject: Re: updating guile-tools: no more --scriptsdir
Date: Wed, 16 Jul 2008 21:45:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() address@hidden (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
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 guile-tools,
which is the basis for this set of proposed (and to be proposed)

You can see the guile-tools in action in Guile-PG's (unreleased, see <>),
lines 51 and 52, for example.



Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]