Re: [PATCH] New language support interface

[Bob Friesenhahn]

On Wed, 17 Mar 2004, Albert Chin wrote:
> >     no-lang         No language support other than C.
> >     all-lang        All supported languages
> >     auto-lang       Automatically detect required support
>
> Ick. What developer using libtool does _not_ know what languages they
> need. Is there every a case where "auto-lang" would not be used?  Why

Me. :-)

Actually, my project doesn't know exactly what languages it needs
until configure time.  If the user doesn't select to build C++ code
then libtool doesn't need to configure C++ and encounter the dreaded
(and deadly) failed /lib/cpp on some platforms.  It would be useful if
a subset of the available configureable tags could be passed at
run-time.

For example, I should be able to set up libtool to support C and C++,
and then only configure libtool for C if the user doesn't select
building any C++ components.

> Have we decided in favor of two macros to initialize libtool,
> LT_INIT([options]), and LT_LANG([tags]) rather than LT_INIT([options],
> [tags])? And, because LT_LANG is only of value to an autoconf-based
> project and if we can now determine what tags the project uses, how
> about we ditch LT_LANG completely. The only reason I ever used
> AC_LIBTOOL_TAGS was because the language tags were not inferred
> correctly.

The reason that I use AC_LIBTOOL_TAGS is to both reduce the size of
the configure script, and to significantly reduce the amount of time
spent configuring.

> > The options cause LT_LANG to be called for each required language.
> > This can be passed either a tag name ("CXX") or an Autoconf-style
> > language name ("C++").
>
> Ick. There should be one way to do it, and one way only.

Right, the Autoconf/GCC way.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen