libtool-wrapper
------------------------------
THIS IS *NOT* GNU libtool

This package provides wrapper scripts to facilitate 
using both "old" and "new" versions of libtool
seamlessly on the same system.  It was developed for
use on the cygwin platform.

By testing the AC_PREREQ line in your project's 
configure.in/.ac file, these scripts set the appropriate 
PATH and environment variables so that the correct version 
(1.4.3 or 1.5) of the desired libtool script is executed.

One the cygwin platform, we have defined the "stable" versions as:
  autoconf-2.13 + automake-1.4-p5 + libtool-1.4.3
and the development versions as
  autoconf-2.5x + automake-1.7.x + hacked libtool-1.5

The determination as to whether to call the "stable" libtool or
the "development" libtool is actually keyed from the *configure.in*
requirement:  if AC_PREREQ(2.13) or less, then we use the stable 
tree -- which means libtool-1.4.2.  Otherwise, we use the development
tree -- which means libtool-1.5.


The user can override the auto-detection behavior in several ways:
  1) set the WANT_LIBTOOL_VER environment to the desired version,
     and the wrapper will apply its usual heuristics.  So,
       WANT_LIBTOOL_VER=1.4.3 (or lower) will invoke stable (*)
       WANT_LIBTOOL_VER=1.5 (or higher) will invoke devel
     (*) actually, anthing < 1.5 will invoke stable
  2) Just set the $PATH -- skip the scripts entirely 
  3) set AUTO_DEVEL=<path to AUTO_STABLE>, or vice versa
Of these mechanisms, the first is especially "dangerous" -- it is 
possible this way to "unbundle" the autotools, and use the stable
version of libtool with the devel version of automake.  Be warned:
this mix-n-match behavior is NOT supported, and NOT tested.

Each wrapper accepts the same arguments as its target and passes
them to the exec'ed process.

Limitations:
------------------------------

(1) pre-autoconfiscation:

Sometimes, it is desirable to run an autotools scripts in a project
directory that has not yet been autoconfiscated, and no 
configure.in/.ac file exists.  In these cases, the heuristics of 
the wrapper will fail -- it is necessary to explicity set your 
PATH variable so that the desired version of the script is 
executed.  `autoscan' from the autoconf package is one tool 
that is often used during the autoconfiscation process (e.g. 
before a configure.in/.ac file exists).

(2) configury outside of srcdir

In packages that use automake, configure will test for the 
existence of autotools with a construct like this:
  if (automake --version) < /dev/null > /dev/null 2>&1; then
    <found>
  else
    <missing>
  fi
However, since this construct is actually calling the wrapper script,
the wrapper will look in the current working directory to determine 
which version is AC_PREREQ'ed by the configure.in file, and the set 
the PATH appropriately and call the desired version -- which will 
then obediently report its version number and exit successfully.

Only one problem: if you run configure from OUTSIDE the package 
source tree, *there's no configure.in in the current directory*.
Therefore, the *wrapper* will report an error, and exit with a failure
code -- leading to a false <missing> diagnosis.  One way this problem
could be solved (without changing the configure script itself):
  if current working dir doesn't contain configure.in, then grep
  'ps' output for $PPID (parent process should be the configure 
  script, in this case). Parsing that for the location of the
  configure script that called the wrapper...
But this is prone to breakage.  Recommeded solution:

  (a) copy the 'real' configure.in into your build dir

  (b) put something like this in your build script:
   -----snip-----
   cd ${builddir}
	if [ ! -f configure.in ] ; then
		cat >configure.in <<-EOF
			# fake configure.in to make the wrapper script happy
			# use whatever version number is appropriate...
			AC_PREREQ(2.13)dnl
		EOF
	fi
   -----snip-----

  (c) set your PATH as appropriate: /usr/autotool/stable|devel/bin
  
Usage and Installation:
-----------------------------

To use these scripts, build and install libtool-1.4.3 with 
--prefix=${prefix-stable}.  Then, build and install 
libtool-1.5 with --prefix=${prefix-devel}.  Finally, 
build and install these scripts using 
--with-devel-prefix=${prefix-devel} and 
--with-devel-prefix=${prefix-stable}.

In other words,

libtool-1.4.3:
  configure --prefix=/usr/autotool/stable
  build, install
libtool-1.5:
  configure --prefix=/usr/autotool/devel
  build, install
libtool-wrapper:
  configure --prefix=/usr \
    --with-stable-prefix=/usr/autotool/stable \
    --with-devel-prefix=/usr/autotool/devel
  build, install
(actually, these are the defaults assumed by libtool-wrapper, so
"configure" with no additional options would work as well).

-------------------------------------------------------

Note that the scripts can be redirected to other autotools
installations, even after the script package has been configured and
installed, by setting the environment variables AUTO_STABLE
and AUTO_DEVEL.  This doesn't affect the "automatic detection" feature
of the wrapper: if the wrapper decides that it is appropriate to call
the devel version, then it will follow the AUTO_DEVEL path (if set).
Else, if it decides to call the stable version, then it will follow
the AUTO_STABLE path.  If these environment variable do not exist, then
the configured stable|devel paths will be used.



