autoconf-patches
[Top][All Lists]
Advanced

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

Re: 01-as-require-shell-fn.patch


From: Akim Demaille
Subject: Re: 01-as-require-shell-fn.patch
Date: Wed, 26 Nov 2003 09:16:29 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

 >> Apply the same idea with an embedded M4sh script containing a simple
 >> 
 >> AS_INIT_WITH_SHELL_FUNCTIONS
 >> 
 >> and I'm happy.

 > I don't understand the need for another macro.  If it does not break
 > configure scripts (and that's why it's using a subshell), why not
 > putting the spy inside them too, so that it gets much more exposure?

Sorry, I don't understand this paragraph (the them in the 3rd line is
obscure to me).


My claim is (was)

- The restarting of the script to find a better shell is handled
  by AS_INIT

- Autotest should be first to use shfn

- Autoconf should be second to use shfn

- Hence we need two flavors of AS_INIT : one for the past, one for
  the future

- We need to have a real audit of shfn support, and neither Libtool
  nor Autotest will ever provide a faithful audit about it.

- So we want to put a probe in the only real scale test: configure
  scripts

- Yeah!  We do have AS_INIT_WITH_SHFN available, so the probe is
  already written: just call AS_INIT_WITH_SHFN in a subshell, and take
  good note of success and failures.

  And the good thing about this, is that the probe is _faithful_: it
  is exactly what Autoconf will do in the future.  The probe shall not
  "does this shell support shfn", because that's not what we care
  about.  The AS_INIT_WITH_SHFN probe will be "does this machine has a
  shell that I can find and which supports shfn".



  Many of Autoconf's failures by the past, and actually many of those
  that push us towards making incompatible changes, were due to the
  lack of faithfulness.  For instance, we don't care about whether cpp
  is happy with a header or not, what matters is what the compiler
  thinks about it.

  So I don't like when we put into Autoconf something which is not
  related to our real problem.  We don't care about shfn support in
  the *current* shell.  That's also what I dislike in your current
  proposal: it doesn't try to restart the script with other shells.

  Having both AS_INIT and AS_INIT_WITH_SHFN does it (almost) for free.


- when Autoconf is ready, AS_INIT_SHFN and AS_INIT will be merged



Is this clearer?




reply via email to

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