On Sat, 2004-04-17 at 22:48, Alexandre Duret-Lutz wrote: > >>> "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.) > > 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool-patches
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool