Why make enable_shared and enable_static specific to a tag? Wouldn't it be odd that you create shared libs for "C" programs and static for "C++"? And, the --enable-shared and --enable-static options would have to multiply (--enable-c-shared, --enable-cxx-shared, etc).
I'm using tags for something different than multi-language operation. I want to confine some configuration changes to a specific library: in particular, I want a particular library to be compiled with -fomit-frame-pointer in an x86 shared library (because it is a bytecode interpreter that is *a lot* slower when a register is used for the GOT pointer), but not in the static library (because it makes debugging harder). There is a precedent in the disable-static and disable-shared tags (however, I think that these two should be obsoleted now that there is -static and -shared, because they are implemented differently than other tags).
See also my AC_LIBTOOL_TAG macro, recently posted in libtool-patches.
In this respect, documenting tag a bit more thoroughly may be a good thing. I will do it if AC_LIBTOOL_TAG is accepted -- otherwise, tags remain little more than an implementation detail and I'd rather use my time to document things for users, since I am mostly a user... :-)
>/ [AC_LIBTOOL_TAGS] is only in CVS/
I can send you a patch against 1.5 if you want.
I already did a backport AC_LIBTOOL_TAGS to 1.5; it is surely saner than m4_define([AC_LIBTOOL_CXX_CONFIG], [:]) which is what I was using :-) before. Thanks for your offer, though.
Paolo
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
