Re: [PATCH] New language support interface

[Scott James Remnant]

On Thu, 2004-03-18 at 03:51, Albert Chin wrote:

> On Wed, Mar 17, 2004 at 08:20:09PM +0000, Scott James Remnant wrote:
> > This removes the AC_LIBTOOL_TAGS macro in favour of a set of LT_INIT
> > options and a new LT_LANG macro to select language support.
> > 
> > The three LT_INIT options are:
> > 
> >     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
> would a C-based project ever want a non-C-based tag?
> 
auto-lang is probably the best default, it hooks whatever language
support they've already enabled through the Autoconf macros.

all-lang is needed for Libtool itself, and probably not much else.  We
want everything on for /usr/bin/libtool after all.

no-lang is there because once language support is enabled, you can't
disable it.  There are people out there who are going to scream because
the C++ parts of their project don't use Libtool, so why is libtool
enabling C++ support? etc.

> Have we decided in favor of two macros to initialize libtool,
> LT_INIT([options]), and LT_LANG([tags]) rather than LT_INIT([options],
> [tags])?
> 
You can only specify one tag with LT_LANG:

        AC_INIT([test], [1])
        LT_INIT([no-lang])

        LT_LANG(C++)
        AC_LANG(C++)
        # tests

        LT_LANG(Fortran 77)
        AC_LANG(Fortran 77)
        # tests

My primary goal with this interface has been consistency, 

The "two-option" form of LT_INIT would then have either been ambiguous
(if a language called "77" comes along later) or would've turned into a
multiple-arg form of LT_INIT.

Neither of these match the interface of Autoconf or Automake, it looks
ugly when no options are specified, makes it unclear what the difference
is between languages and options and promotes language selection further
than we should (the default should work for 95% of people) so I
discarded the idea.

> 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.
> 
_LT_LANG (a different macro) is required in order for Automake and
friends to trace what tags Libtool is going to support.  That is the
macro that does most of the work.

LT_LANG is basically just a friendly wrapper around it, so there's
little gain in throwing it away.  It's there for those people I
mentioned above who will be unhappy with the default automatic support.

You'll note that the documentation doesn't promote it heavily, only in
combination with the 'no-lang' option.

> > 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.
> 
The Autoconf-style names are the ones documented for end-users, however
internally (for various reasons) Libtool uses the tag names instead, so
it's worth mentioning here so the other developers don't get surprised
by things that don't use them in the source :-)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

signature.asc
Description: This is a digitally signed message part