>>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool