On Tue, 3 Jun 2003, Alexandre Duret-Lutz wrote: > >>> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: > > [...] > > Albert> I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or > Albert> AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? > > As a user I wouldn't care about this little inconvenience if it > allows Libtool not to bloat my configure with useless checks. > > However, requiring this will break thousands of configure.ac. I > expect most of them to run AC_INIT, AM_INIT_AUTOMAKE, > AC_PROG_LIBTOOL early, and then go on with other checks such as > language checks.
This is true. It may be very inconvenient for some packages to change the ordering. > Maybe this could be changed as follows: It is generally not a good approach to base a design on side-effects or assumptions. Up to now, adding AC_PROG_LIBTOOL to a configure.ac file has been sufficient to configure libtool, regardless of whether libtool is stand-alone or embedded. This behavior should not be altered. I believe that a much better solution is to add a AC_LIBTOOL_TAGS (or AC_LIBTOOL_LANGUAGES) macro which can be used like AC_LIBTOOL_TAGS([c c++]) AC_PROG_LIBTOOL This option specification macro would be used in a similar way to the existing AC_DISABLE_SHARED & AC_ENABLE_STATIC options to pass options to AC_PROG_LIBTOOL. _LT_AC_TAGCONFIG can be updated to recognize when AC_LIBTOOL_TAGS has been executed, and to use the tagnames value it provides. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
