Re: about libtool's trace interface for tags (gah, went to wrong list)

[Scott James Remnant]

On Sat, 2004-04-17 at 22:48, Alexandre Duret-Lutz wrote:

> >>> "Scott" == Scott James Remnant <address@hidden> writes:
> 
>  Scott> On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote:
>  >> Ah, thanks!  Sorry for being dense, but since it takes
>  >> tag names as argument, why is it called _LT_LANG?  
>  >> 
>  Scott> Because it actually takes language configuration names, which just
>  Scott> happen to be the same as the tags that get generated.  (There's a 
> patch
>  Scott> floating around by me that breaks that assumption.)
> 
> What is the difference between 
>    a tag name
>    a language configuration name
>    a language name
>    an internal name
> ?
> 
Ok... here's how I see it:

A tag name is the name of a configuration block placed inside the
generated libtool script.  They can be automatically inferred by the
compiler name, or selected with the --tag=TAG option.

A language name is the name of a language that Libtool supports, which
are deliberately the same as Autoconf language names.  They're
human-parseable and the current list is "C", "C++", "Java", "Fortran 77"
and "Windows Resource".

A language configuration name is an internal name for the human language
names ... they're basically the $1 in _LT_LANG_$1_CONFIG which are the
macros that actually configure them.  In current HEAD, they always match
the tag name,


A user can place LT_LANG(language name) in their configure.ac to enable
a language, this calls _LT_LANG(language configuration name) to actually
enable it.

A user can place AC_PROG_CXX in their configure.ac and Libtool will
automatically enable that language by calling LT_LANG (for some on-crack
reason, it uses internal names but that's irrelevant :p).

> So far I had been assuming that there was only to sort of names:
> language names (passed as argument to LT_LANG), and tag names
> (passed as arguments to --tag=).
> 
> What exactly is the assumption that you'll break?  The arguments
> passed to _LT_LANG will not always be tag names?  If so I'm
> afraid Automake cannot use this macro.  (See below.)
> 
I'm not entirely sure it'll ever break, when I wrote the LT_LANG support
it was actually quite a bit wilder than the patch I committed.  There's
an RFC patch (keybuk-lt-tag.patch) that adds the wildness.

It basically allows users to define their own tags:
        # Default F77 support
        LT_LANG(Fortran 77)

        # Create a C++ language tag called BINCXX
        LT_LANG(C++, BINCXX)

The idea would be you can go:
        CXX="/some/other/cxx"
        LT_LANG(C++, OTHERCXX)
To enable support for multiple C++ compilers and the like.

With this patch, _LT_LANG gets called with two arguments; the first is
the language configuration name, the second the resulting tag name.

But this isn't the current state of HEAD.

>  Scott> LT_LANG is the public-facing version of this macro,
>  Scott> which takes "friendly" names like 'C++' and 'Fortran
>  Scott> 77'.  It then calls _LT_LANG with the internal name,
>  Scott> which is the most convenient trace point for you.
> 
> I don't want Automake to rely on anything internal to Libtool.
> This is not a safe road.  If Libtool use some *internal* names,
> Automake should not rely on them.
> 
Fair enough...

> I couldn't find the documentation for libtool's --tag=TAG
> option, by I'm assuming it's a public option.  It's list of
> allowed argument is therefore something public too.  I will call
> these arguments "tags".
> 
Yup, that's correct ... it's what ends up in available_tags in libtool
and comes from the content of the _LT_TAGS macro.

> In order to generate Makefiles, Automake needs to know what
> language libtool has been configured for, and the corresponding
> tags to pass to the --tag option.
> 
> So far I have been assuming that there would be a macro to trace
> that would return a list of enabled tags.
> 
The trouble is that tracing doesn't work like that, when you trace you
don't get a definition or a "return value", you see the arguments passed
to the macro.

AC_DEFUN([TRACE_ME_PLENTY], [])
TRACE_ME_PLENTY(foo, bar)

configure.ac:999:TRACE_ME_PLENTY:foo:bar


This makes _LT_LANG a nice thing to trace, because it's part of the
internal macro set to enable language support and happens to take
arguments useful to you.  _LT_CONFIG would be equally traceable for the
same reason, it's just a bit further down the stack.

(_LT_LANG calls _LT_LANG_*_CONFIG to configure a language will calls
_LT_CONFIG to add a tag to the resulting file).


This is why tracing _LT_TAG which is used during _LT_CONFIG to store the
current tag name, and _LT_TAGS which contains the list of tags is
worthless.  They're defined to contain things, but never expanded with
arguments.
        
> I have also been
> assuming that the set of possible tags returned by this macro
> was constant (more precisely adding tags for new language is OK,
> but renaming the tag of an existing language is not).  Automake
> knows these tags (these are public so it's ok) and can make the
> correspondence with the languages it supports.
> 
> In other words, automake traces tags and uses these both as
> arguments to --tag and as unique identifier for languages.
> 
> I your first statement implies that the tags will be renamed
> into language configuration names, then we must work out a more
> complex interface.  Something that return pairs of 
> (unique-language-id, tags) for instance.  I hope we won't
> have to do this, though.
> 
If we go down that road, whatever you trace will return these pairs
yes.  For now, the tag names also happen to be a 1-1 match with what I
call language configuration names :-)

>  Scott> The trouble with making public macros is people will
>  Scott> tend to put them in their configure.ac, no matter how
>  Scott> large the instruction telling them not to.
> 
> But you don't need to describe it as a macro if you prefer.  For
> instance in the documentation for the --tag=TAG option there
> will likely be a list of allowed tags, and it would sound
> appropriate to state something like:
> 
>   It is sometimes helpful to query the list of tags configured
>   in a package from a script or some automated tool.  This can
>   be done using `autoconf --trace LT_SUPPORTED_TAG=\$1'.
> 
> Or something along these lines.  
> 
This would have to be an empty macro called with an appropriate
argument, renaming _LT_LANG would confuse the hell out of anyone trying
to follow how language support gets enabled...

Something like...

        # LT_SUPPORTED_TAG(TAG)
        # ---------------------
        # Trace me to discover what tags are supported by the --tag option
        AC_DEFUN([LT_SUPPORTED_TAG], [])

Then make _LT_LANG something like:

        # _LT_LANG(LANGNAME)
        # ------------------
        m4_define([_LT_LANG],
        [m4_ifdef([_LT_LANG_]$1[_enabled], [],
==>       [LT_SUPPORTED_TAG($1)
          m4_append([_LT_TAGS], [$1 ])dnl
          m4_define([_LT_LANG_]$1[_enabled], [])dnl
          _LT_LANG_$1_CONFIG($1)])dnl
        ])# _LT_LANG

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

_______________________________________________
Libtool-patches mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool-patches