Re: [shell functions, was RE: solving of name conflicts in included . a]

[Charles Wilson]

On the other hand, autoconf's most recent release sez (as ADL pointed 
out before I finished composing this message):

------------------------------------------------
** Plans for 2.56

...
- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  address@hidden
-------------------------------------------------

When will libtool-1.5 be released?   Before or after ac-2.56? (given 
that ac-2.55 will be released next week).

Assuming that the autoconf people have not repudiated their plan to 
integrate shell functions starting in 2.56, then the decision to use 
them in libtool or not could be better stated as

"Shall libtool-1.5 require autoconf-2.56?"

Because, if autoconf-2.56 uses shell functions, then if libtool-1.5 
requires ac-2.56 then ipso facto libtool-1.5 is also permitted to use 
shell functions.

The next question is how gracefully should libtool degrade if the 
buildhost shell doesn't support shell functions.  Blindly adding them 
into ltmain.sh or into the macros in libtool.m4 (like my patch did) ---> 
breaks libtool completely even on platforms that don't themselves use 
the shell functions (if the platform's shell doesn't support ...)

That's probably not a good idea during the transitional period (assuming 
there will be a transition at all, e.g. assuming ac-2.56 will follow 
through on its promise to start using shell functions)

Searching the libtool archives reveals that this topic has come up 
before.  Somebody (Gary?) once suggested using some mechanism to either 
declare the shell functions, or create separate standalong scripts for 
each shell function on buildhosts that don't support them...for example:

libtoolize will copy into the <srcdir>:

<srcdir>/ltmain.sh
<srcdir>/ltshfunc.sh

during configure, while building libtool:

if shell functions supported, then
  . ltshfunc.sh
else
  <run some set of code that parses ltshfunc.sh
   and turns it into a set of separate, appropriately
   named, scripts>
endif

Downside: in the "use shell funcs" case, libtool would contain code like
  result=`win32_libid $bob $george`
which works fine when win32_libid is a shell function.  But if we have a 
script called "win32_libid" in the same directory where libtool is, then 
that won't work.  You'd need to do

tdir=`echo "$0" | sed 's%[\\/][^\\/][^\\/]*$%%'`
test "x$tdir" = "x$0" && tdir=.
sdir=`cd $tdir; pwd`
sdir="${sdir}/"
...
result=`${scriptdir}win32_libid $bob $george`

or somesuch.

--Chuck