* PORTING: removed the text Akim Demaille converted to .texi

* doc/libtool.texi: converted inter-library dependencies
 	instructions from PORTING

ChangeLog

@@ -1,5 +1,14 @@
 1998-12-09  Alexandre Oliva  <oliva@dcc.unicamp.br>
 
+	* PORTING: removed the text Akim Demaille converted to .texi
+
+1998-12-09  Akim Demaille  <demaille@inf.enst.fr>
+
+	* doc/libtool.texi: converted inter-library dependencies
+ 	instructions from PORTING
+
+1998-12-09  Alexandre Oliva  <oliva@dcc.unicamp.br>
+	
 	* ltmain.in (convenience, deplibs): propagate dependencies
 	* libltdl/Makefile.am (noinst_HEADERS): don't install ltdl.h yet
 	(noinst_LTLIBRARIES): ditto for libltdl.la

PORTING

@@ -1,66 +1,6 @@
 In order to port libtool to a new platform, start by reading the node
-`New ports' in the info document (i.e., the libtool manual).  Some
+`New ports' in the info document (i.e., the libtool manual).
-additional information, that has not been converted to the .texi
-format yet, is available in this file.
 
 If you find that any porting documentation is missing, please
 complain! :-) Complaints with patches and improvements to the
 documentation, or to libtool itself, are more than welcome.  :-) :-)
-
-
-Inter-library Dependencies
---------------------------
-
-libtool 1.2c has re-introduced the ability to do inter-library
-dependency on some platforms, thanks to a patch by Toshio Kuratomi
-<badger@prtr-13.ucsc.edu>.  Here's a shortened version of the message
-that contained his patch:
-
-The basic architecture is this: in ltconfig.in, the person who writes
-libtool makes sure $deplibs is included in $archive_cmds somewhere and
-also sets the $check_shared_deplibs_method.
-check_shared_deplibs_method can be any of five things:
-    test_compile
-    file_regex
-    file_magic [regex]
-    pass_all
-    none
-
-I think that file_magic works the best: It looks in the library link
-path for libraries that have the right libname.  Then it runs file on
-the library and checks for a match against [regex] using expr.  I
-currently have linux-elf looking for the string: "ELF 32-bit LSB
-shared object" which seems to work well.  (I don't know whether the
-"32-bit" would have to change on linux-alpha though....  change to
-'ELF [0-9]+-bit LSB shared object' might work.  I don't know.)
-
-file_regex will look for a filename in the link path.  It doesn't take
-an argument because I use the libname_spec and library_names_spec
-variables to create the string to look for.  I don't like it because
-symlinks and random files can make it give false positives.
-
-test_compile handles -L correctly, I hope.  It also takes the names of
-it's libraries from libname_spec instead of a hardcoded lib`expr
-$a_deplib : '-l/(.*/)'`.so line.
-
-pass_all will pass everything without any checking.  I put it in
-because osf3&4 appear to be treated that way right now...  It might be
-wise to perform checks here to see if the libraries exist on the
-system, but I don't know how osf3&4 handle that, so I thought it would
-be better just to do it the way the current code does.
-
-none is the default for all systems unless overridden in ltconfig.in
-(Currently, linux-elf is the only system that overrides.)  It causes
-deplibs to be reassigned deplibs="".  That way archive_cmds can
-contain deplibs on all platforms, but not have deplibs used unless
-needed.
-
-Okay:: Then in ltmain.in we have the real workhorse: a litle
-initialization and postprocessing (to setup/release variables for use
-with eval echo libname_spec etc.) and a case statement that decides
-which method is being used.  This is the real code... I wish I could
-condense it a little more, but I don't think I can without function
-calls.  I've mostly optimized it (moved things out of loops, etc) but
-there is probably some fat left.  I thought I should stop while I was
-ahead, work on whatever bugs you discover, etc before thinking about
-more than obvious optimizations.

doc/libtool.texi

@@ -192,6 +192,11 @@ Maintenance notes for libtool
 * libtool script contents::     Configuration information that libtool uses.
 * Cheap tricks::                Making libtool maintainership easier.
 
+Porting libtool to new systems
+
+* Information sources::         Where to find relevant documentation
+* Porting inter-library dependencies::  Implementation details explained
+
 Platform quirks
 
 * References::                  Finding more information.
@@ -2666,6 +2671,18 @@ Before you embark on porting libtool to an unsupported system, it is
 worthwhile to send e-mail to @value{BUGADDR}, to make sure that you are
 not duplicating existing work.
 
+If you find that any porting documentation is missing, please complain! 
+Complaints with patches and improvements to the documentation, or to
+libtool itself, are more than welcome.
+
+@menu
+* Information sources::         Where to find relevant documentation
+* Porting inter-library dependencies::  Implementation details explained
+@end menu
+
+@node Information sources
+@subsection Information sources
+
 Once it is clear that a new port is necessary, you'll generally need the
 following information:
 
@@ -2718,6 +2735,71 @@ the @code{ltmain.sh} script accordingly.  Be sure to write to the
 mailing list before you make changes to @code{ltmain.sh}, since they may
 have advice on the most effective way of accomplishing what you want.
 
+@node Porting inter-library dependencies
+@subsection Porting inter-library dependencies support
+@cindex inter-library dependency
+@vindex check_shared_deplibs_method
+
+Since version 1.2c, libtool has re-introduced the ability to do
+inter-library dependency on some platforms, thanks to a patch by Toshio
+Kuratomi @email{badger@@prtr-13.ucsc.edu}.  Here's a shortened version
+of the message that contained his patch:
+
+The basic architecture is this: in @file{ltconfig.in}, the person who
+writes libtool makes sure @samp{$deplibs} is included in
+@samp{$archive_cmds} somewhere and also sets the
+@samp{$check_shared_deplibs_method}.  @samp{check_shared_deplibs_method}
+can be any of five things:
+@table @samp
+@item file_magic [@var{regex}]
+@vindex file_magic
+looks in the library link path for libraries that have the right
+libname.  Then it runs file on the library and checks for a match
+against [regex] using expr.  I currently have linux-elf looking for the
+string: "ELF 32-bit LSB shared object" which seems to work well.  (I
+don't know whether the "32-bit" would have to change on linux-alpha
+though....  change to 'ELF [0-9]+-bit LSB shared object' might work.  I
+don't know.)  This is one that works best I think.
+
+@item file_regex
+@vindex file_regex
+will look for a filename in the link path.  It doesn't take an argument
+because I use the @samp{libname_spec} and @samp{library_names_spec}
+variables to create the string to look for.  I don't like it because
+symlinks and random files can make it give false positives.
+
+@item test_compile 
+@vindex test_compile
+handles @samp{-L} correctly, I hope.  It also takes the names of it's
+libraries from libname_spec instead of a hardcoded lib`expr $a_deplib :
+'-l/(.*/)'`.so line.
+
+@item pass_all
+@vindex pass_all
+will pass everything without any checking.  I put it in because osf3&4
+appear to be treated that way right now...  It might be wise to perform
+checks here to see if the libraries exist on the system, but I don't
+know how osf3&4 handle that, so I thought it would be better just to do
+it the way the current code does.
+
+@item none
+@vindex none
+is the default for all systems unless overridden in @file{ltconfig.in}
+(Currently, linux-elf is the only system that overrides.)  It causes
+deplibs to be reassigned deplibs="".  That way @samp{archive_cmds} can
+contain deplibs on all platforms, but not have deplibs used unless
+needed.
+@end table
+
+Then in @file{ltmain.in} we have the real workhorse: a litle
+initialization and postprocessing (to setup/release variables for use
+with eval echo libname_spec etc.) and a case statement that decides
+which method is being used.  This is the real code... I wish I could
+condense it a little more, but I don't think I can without function
+calls.  I've mostly optimized it (moved things out of loops, etc) but
+there is probably some fat left.  I thought I should stop while I was
+ahead, work on whatever bugs you discover, etc before thinking about
+more than obvious optimizations.
 
 @node Tested platforms
 @section Tested platforms