Hi Charles,
* Charles Wilson wrote on Sun, Feb 21, 2010 at 07:19:53AM CET:
> Document wrapper changes.
> * NEWS: Indicate new feature and incompatibility.
> * doc/libtool.texi [Linking executables]: Mention wrapper
> executables, in addition to wrapper scripts. Add menu
> referencing subsection 'Wrapper executables for programs'.
> [Wrapper executables for programs]: New subsection. Documents
> cwrapper rationale and command line options.
Ok with nits below addressed, and after testing 'make info ps pdf html'.
Thanks!
Ralf
> --- a/NEWS
> +++ b/NEWS
> @@ -16,6 +16,17 @@ New in 2.2.8 2010-??-??: git version 2.2.7a, Libtool team:
> runs on Windows with popup windows in the middle, and `check-interactive'
> for the complement set of tests.
> - New link mode flag -bindir to specify the location for installed PE DLLs.
> + - Wrapper scripts and wrapper executables for programs linked against
> + uninstalled shared libraries now support command-line options --lt-debug
> + and --lt-dump-script.
> +
> +* Important incompatible changes:
> +
> + - The wrapper command line option support described above introduces the
> + following incompatibility: the wrapper will remove any command line
> + options that begin with '--lt-*' from the argument list before launching
> + (uninstalled) programs. Any '--lt-*' option on the command line not
> + recognized by the wrapper will result in an error.
>
> * Changes in supported systems or compilers:
>
> diff --git a/doc/libtool.texi b/doc/libtool.texi
> index 482e635..aa29db8 100644
> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -790,8 +790,9 @@ Note that libtool added the necessary run-time path flag,
> as well as
> @cindex wrapper scripts for programs
> @cindex program wrapper scripts
> Notice that the executable, @code{hell}, was actually created in the
> -...@file{@value{objdir}} subdirectory. Then, a wrapper script was created
> -in the current directory.
> +...@file{@value{objdir}} subdirectory. Then, a wrapper script (or, on
> +certain platforms, a wrapper executable @pxref{Wrapper executables}) was
> +created in the current directory.
>
> Since libtool created a wrapper script, you should use libtool to
> install it and debug it too. However, since the program does not depend
> @@ -845,6 +846,60 @@ price of being dynamic is eight kilobytes, and the
> payoff is about four
> kilobytes. So, having a shared @file{libhello} won't be an advantage
> until we link it against at least a few more programs.
>
> +...@menu
> +* Wrapper executables:: Wrapper executables for some platforms.
> +...@end menu
> +
> +...@node Wrapper executables
> +...@subsection Wrapper executables for programs
s/programs/uninstalled &/ ?
Don't you need to repeat the menu entry somewhere in the toplevel
@detailmenu?
> +...@cindex wrapper executables for programs
> +...@cindex program wrapper executables
> +
> +Some platforms, notably those hosted on Windows such as Cygwin
> +and MinGW, use a wrapper executable rather than a wrapper script
> +to ensure proper operation of programs linked by libtool against
s/programs/uninstalled &/ ?
> +uninstalled shared libraries. The wrapper executable thus performs
> +the same function as the wrapper script used on other platforms, but
> +allows to satisfy the @command{make} rules for the program, whose
> +name ends in @code{$(EXEEXT)}. The actual program executable is
> +created below @value{objdir}, and its name will end in @code{$(EXEEXT)}
> +and may or may not contain an @code{lt-} prefix. This wrapper
> +executable sets various environment values so that the program
> +executable may locate its (uninstalled) shared libraries, and then
> +launches the program executable.
[...]
