[Top][All Lists]

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

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

From: Charles Wilson
Subject: Re: [shell functions, was RE: solving of name conflicts in included . a]
Date: Thu, 07 Nov 2002 15:13:07 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

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

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 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>:


during configure, while building libtool:

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

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`
result=`${scriptdir}win32_libid $bob $george`

or somesuch.


reply via email to

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