[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] New language support interface

From: Bob Friesenhahn
Subject: Re: [PATCH] New language support interface
Date: Wed, 17 Mar 2004 22:10:39 -0600 (CST)

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

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 Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]