| > From: Akim Demaille <[EMAIL PROTECTED]> | > Date: 13 Mar 2002 10:41:09 +0100 | | > Actually, all this should be done after an initial step, which is | > equipping configure with means to provide replacement functions. I'm | > think about something like | > | > ./configure --replacement-function=ln -s from to | > | > ./configure --replacement-function=echo "Hello world" | > | > and so forth. | | Hmm, won't this make configure scripts harder to read and generate, | and slower to boot? Perhaps I'm missing something here....
Harder to read, well, maybe, but they already are. As a matter of fact, I'm convinced it can make it much more readable, as with less inline expansion and more explicit names. Harder to generate. I'm convinced that it is not the case. Diversion rulez. Slower to boot. Well maybe I don't know. But with a more efficient body on average machines, I'm quite sure. Look at the expansion of a simple AS_DIRNAME, and imagine it's now only `$dirname /foo/bar' with $dirname being typically dirname. | | How about this idea instead. Let the configure script contain code | that looks like this: | | ln -s from to | echo "Hello world" | | in both cases assuming the POSIX.1-2001 semantics. | | On hosts that don't have the standard semantics, supply either a shell | function (if supported) or a shell script prepended to the PATH (if | shell functions don't work) that has the desired semantics. | | This approach would be easier to explain for people writing | configure.ac files, as they can assume the standard semantics for | standard shell utilities. They won't have use fancy Autoconf macros | to invoke standard shell utilities. This does not meet the users' expectations. They don't want satellite tools. This is why I meant to wrap all these people into configure. In addition, in the general case, I'm interested in having self contained scripts. Don't forget behind the scene there is M4sh.
