libtool/TODO

For next public release:
************************

* For every `-L' flag, hardcode a corresponding directory.  For
aesthetics and least redundancy, this should only be done once for
each dir (i.e. no duplicates).  So, if the expansion is the same as
`-Llibdir', then don't add anything.  Also, check that directories
added by this feature do not duplicate flags added with `-rpath'.

The question is: should this only be done for programs?  The answer
is, I think, YES!  Libtool libraries and inter-library dependencies
are tricky enough without trying to factor in this complexity.

* Document `execute' mode, and the experimental nature of -dlopen and
-dlpreopen.

Franc,ois Pinard about debugging:

``Another thing I'm curious to experiment is how will `gdb' perform
with shared libraries.  There are a few notes in the manual about
generating a "more easy to debug" version of the program.  I tried the
recipe, but it broke somewhere in Automake generated dependency code,
so I got to remove it for now.  However, the manual does not explain
what the debugging difficulty is, and so, I wonder what problems I
will meet.''

* Document the change from `-allow-undefined' to `-no-undefined'.

* Some packages, such as GIMP, choose to put a note about
`--disable-shared' in their README:

----------------------------------------------------------------------
The GIMP uses GNU libtool in order to build shared libraries on a
variety of systems. While this is very nice for making usable
binaries, it can be a pain when trying to debug a program. For that
reason, compilation of shared libraries can be turned off by
specifying the "--disable-shared" option to "configure".
----------------------------------------------------------------------
Simply invoke configure in the top-level directory.  Besides the usual
GNU configure options, there are the following SANE specific options:

 --disable-shared
	Don't use shared libraries.  Useful for debugging or when there
	is a problem building shared libraries.
----------------------------------------------------------------------

Perhaps a similar note could be added to ABOUT-NLS.

I'll add a suggestion to the libtool documentation, so that other
maintainers add this kind of note to their package documentation.  The
biggest motivation, mentioned by Franc,ois Pinard, is to turn off
double-compilation.

* Bengt Martensson says:

"Some compilers may allow identifiers which are not legal in ANSI C,
for example dollar signs. Such symbols will not be exported. Only
symbols which are legal in ANSI C (ASCII letters, digits, and
underscore; not starting with a digit) are exported."

In the future:
**************

* Inter-library dependencies should be automatically tracked by
libtool.  Reminded by Alexandre Oliva.  This also would require
looking up installed libtool libraries for transparent support.

* Implement full multi-language support.  Currently, this is only for
C++, but there are beginnings of this in the manual (Other Languages).
This includes writing libtool not to be so dependent on the compiler
used to configure it.

We especially need this for C++ linking, for which libtool currently
does not handle static constructors properly, even on operating
systems that support them.  ``Don't use static constructors'' is no
longer a satisfactory answer.

People who need it:
  Jean Daniel Fekete <Jean-Daniel.Fekete@emn.fr>
  Thomas Hiller <hiller@tu-harburg.d400.de>

* Writing libtool as a shell script means that proper variable quoting
is a real problem.  Be careful when `eval'ing a string that the
arguments are properly quoted.  Note that arguments with embedded
whitespace probably will cause problems (because of IFS).

I don't have good ideas on to fix the problems with whitespace, other
than subverting IFS entirely, perhaps always using an `eval "set
$quoted_args"' sequence.

* Another form of convenience library, suggested by Alexandre Oliva,
is to have undocumented utility libraries, where only the shared
version is installed.

* We could use libtool object convenience libraries that resolve
symbols to be included in a libtool archive.

* Somehow we need to make sure that static libraries never appear in
$deplibs.  This, will probably require that libtool discover exactly
which files would be linked from which directories when somebody says
`-lsomething'.  This adds a lot of complexity, but I see no other way
around it.

* Need to finalize the documentation, and give a specification of
`.la' files so that people can depend on their format.  This also
needs to be done so that DLD uses a public interface to libtool
archives.  This would be a good thing to put before the maintainance
notes.

Things to think about:
**********************

* Implement full support for other orthogonal library types
(libhello_g, libhello_p).  Make these types configurable.  Some
thinking will have to be done about the defaults, and what libhello
(standard type) should be.

Maybe we should just add an autoconf macro and get creative with
library_transform_name, or something.  These changes should be
partially driven by the needs of packaging tools, such as RPM and
dpkg.

* Talk with RMS about his so-called `automatic package generation
tool.'  This is probably what Thomas has been murmuring about for the
Hurd.  We'll need to integrate package-supplied programs such as
libtool into that scheme, since it manages some of the preinstall and
postinstall commands, but isn't installed itself.  Probably, things
like libtool should be distributed as part of such a binary package.

* Add support for windoze DLL's, and maybe other jumptable libs.
Check out Lesstif and Tcl configuration again (maybe they would be
interested in libtool by now?).  The Cygnus win32 project may also be
of value, though it still seems pretty rudimentary right now.