[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about libtool's trace interface for tags
From: |
Scott James Remnant |
Subject: |
Re: about libtool's trace interface for tags |
Date: |
Sat, 17 Apr 2004 23:38:24 +0100 |
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
- Re: about libtool's trace interface for tags,
Scott James Remnant <=