Re: about libtool's trace interface for tags

[Alexandre Duret-Lutz]

>>> "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.)

Sorry for the delay.  

Sorry also if this mail look uselessly long and finicky, but I
am really confused and worried by your last comment.

I must also precise I'm not reading everything on libtool@ and
libtool-patches@, so I'm not aware of all the latest
developments and patches floating around.  Obviously my
vocabulary is also out of date :)

What is the difference between 
   a tag name
   a language configuration name
   a language name
   an internal name
?

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.)

 >> How about calling it `LT_SUPPORTED_TAG' or something similar?  I
 >> can supply a patch to rename and document this macro in the
 >> manual, if that sounds OK.  I really think that this interface
 >> should be public, like every other traced macros (at least all
 >> those registered in autom4te.cfg).
 >> 
 Scott> Because it isn't public ... 

Call it a storm-resistant interface for third-party tools :)

 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.


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".

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.  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.

 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.  

Personally I would find more natural to have a `Tracing
Interface' node listing all such macros of interest.  Even if
there is only one macro for now, this will make room for future
additions, and clearly state what macro it is OK to trace (so
that you don't have to care about people that abusively trace
the inner guts of Libtool).  

I don't think people will monkeyly copy random documented macros
to their configure.ac to see how they help breaking their
package; but if they do, it's really their problem.  Monkeys
should not hinder the development of useful features :)
-- 
Alexandre Duret-Lutz