Re: 1.5 automatically generating C++, F77 tags
Albert Chin [EMAIL PROTECTED] writes: This means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. It'd be nice to have both an autoconf-time AC_LIBTOOL_TAGS and then also some way to further limit it at configure-time from within the configure script. In gmp for instance C++ support is optional, and it's nice not to execute the C++ configury when not enabled. Not that it does any active harm, but just to save time and not confuse the user. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote:
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
[ snip snip ]
Ok, just whipped this up as a proof of concept. Haven't really tested.
Am I headed in the right direction.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
--- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
+++ libtool.m4 2003-06-03 10:22:57.667598339 -0500
@@ -39,35 +39,9 @@
# ---
AC_DEFUN([AC_PROG_LIBTOOL],
[AC_REQUIRE([_AC_PROG_LIBTOOL])dnl
-dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
-dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX.
- AC_PROVIDE_IFELSE([AC_PROG_CXX],
-[AC_LIBTOOL_CXX],
-[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
- ])])
-dnl And a similar setup for Fortran 77 support
- AC_PROVIDE_IFELSE([AC_PROG_F77],
-[AC_LIBTOOL_F77],
-[define([AC_PROG_F77], defn([AC_PROG_F77])[AC_LIBTOOL_F77
-])])
-
-dnl Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
-dnl If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
-dnl AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
- AC_PROVIDE_IFELSE([AC_PROG_GCJ],
-[AC_LIBTOOL_GCJ],
-[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [AC_PROVIDE_IFELSE([LT_AC_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [ifdef([AC_PROG_GCJ],
-[define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([A][M_PROG_GCJ],
-[define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([LT_AC_PROG_GCJ],
-[define([LT_AC_PROG_GCJ],
- defn([LT_AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])])])
-])])# AC_PROG_LIBTOOL
+AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
+ [AC_LIBTOOL_TAGS([C C++ F77])])
+]) # AC_PROG_LIBTOOL
# _AC_PROG_LIBTOOL
@@ -1608,15 +1581,26 @@
])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
+# AC_LIBTOOL_TAGS
+# ---
+# tags to enable
+AC_DEFUN([AC_LIBTOOL_TAGS],
+[m4_define([_LT_TAGS],[$1])
+]) # AC_LIBTOOL_TAGS
+
+# _LT_AC_CHECK_TAG
+#
+AC_DEFUN([_LT_AC_CHECK_TAG],
+[if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $1$ ${ofile} /dev/null
+then
+AC_MSG_ERROR([tag name \$1\ already exists])
+fi
+]) # _LT_AC_CHECK_TAG
+
# _LT_AC_TAGCONFIG
#
AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
-[AC_HELP_STRING([--with-tags@:@=TAGS@:@],
-[include additional configurations @:@automatic@:@])],
-[tagnames=$withval])
-
-if test -f $ltmain test -n $tagnames; then
+[if test -f $ltmain test -n _LT_TAGS; then
if test ! -f ${ofile}; then
AC_MSG_WARN([output file `$ofile' does not exist])
fi
@@ -1634,66 +1618,37 @@
# Note that this assumes the entire list is on one line.
available_tags=`grep ^available_tags= ${ofile} | $SED -e
's/available_tags=\(.*$\)/\1/' -e 's/\//g'`
- lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
- for tagname in $tagnames; do
-IFS=$lt_save_ifs
-# Check whether tagname contains only valid characters
-case `$echo X$tagname | $Xsed -e
's:[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]::g'` in
-) ;;
-*) AC_MSG_ERROR([invalid tag name: $tagname])
- ;;
-esac
-
-if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$ ${ofile} /dev/null
-then
- AC_MSG_ERROR([tag name \$tagname\ already exists])
-fi
-
-# Update the list of available tags.
-if test -n $tagname; then
- echo appending configuration tag \$tagname\ to $ofile
-
- case $tagname in
- CXX)
- if test -n $CXX test X$CXX != Xno; then
- AC_LIBTOOL_LANG_CXX_CONFIG
- else
- tagname=
- fi
- ;;
-
- F77)
- if test -n $F77 test X$F77 != Xno; then
- AC_LIBTOOL_LANG_F77_CONFIG
- else
- tagname=
-
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote: 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 means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. I'll try and code this up. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, 3 Jun 2003, Albert Chin wrote: AC_LIBTOOL_TAGS([c c++]) AC_PROG_LIBTOOL This means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. I am also in favor of either getting rid of --with-tags, or supporting it via a configure.ac macro that the package author needs to add. Currently libtool adds a --with-tags option to the configure script for each package which uses it. This is confusing to package users since there is no context associated with the option: --with-tags[=TAGS] include additional configurations [automatic] An option like --with-libtool-languages[=languages] would be clearer for an end user. However, I would also contend that end-users should have no need to be aware that a package uses libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 10:58:14AM -0500, Bob Friesenhahn wrote: On Tue, 3 Jun 2003, Albert Chin wrote: AC_LIBTOOL_TAGS([c c++]) AC_PROG_LIBTOOL This means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. I am also in favor of either getting rid of --with-tags, or supporting it via a configure.ac macro that the package author needs to add. Currently libtool adds a --with-tags option to the configure script for each package which uses it. This is confusing to package users since there is no context associated with the option: --with-tags[=TAGS] include additional configurations [automatic] An option like --with-libtool-languages[=languages] would be clearer for an end user. However, I would also contend that end-users should have no need to be aware that a package uses libtool. I think --with-libtool-languages and AC_LIBTOOL_TAGS are mutually exclusive. For example: AC_LIBTOOL_TAGS([C]) AC_PROG_LIBTOOL and then --with-libtool-languages=C++ is useless because the C++ glue code won't be in configure. --with-libtool-languages means that every tag has to be present in configure. Ick. Ditch --with-tags! -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert Chin [EMAIL PROTECTED] writes: [...] | --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500 | +++ libtool.m42003-06-03 10:22:57.667598339 -0500 [...] | +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],, | + [AC_LIBTOOL_TAGS([C C++ F77])]) Since the tag for C++ is called CXX and there is no tag for C, it would seem more natural to read AC_LIBTOOL_TAGS([CXX F77]) I think Bob's suggestion of AC_LIBTOOL_LANGUAGES is better if you really want to pass language names as arguments. [...] | + [m4_if(_LT_TAG, C, , | + [m4_if(_LT_TAG, C++, [...] | + [m4_if(_LT_TAG, F77, [...] | + [m4_if(_LT_TAG, GCJ, [...] | + [m4_if(_LT_TAG, RC, [...] | + m4_errprintn(m4_location[: error: invalid tag name: ]_LT_TAG) Maybe this can be simplified to something around the lines of m4_case([_LT_TAG], [C], , [CXX], [...], [F77], [...], [GCJ], [...], [RC], [...], [m4_fatal([unsupported tag name: ]_LT_TAG)]) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, 3 Jun 2003, Albert Chin wrote: I think --with-libtool-languages and AC_LIBTOOL_TAGS are mutually exclusive. For example: AC_LIBTOOL_TAGS([C]) AC_PROG_LIBTOOL and then --with-libtool-languages=C++ is useless because the C++ glue code won't be in configure. --with-libtool-languages means that every tag has to be present in configure. Ick. Ditch --with-tags! If libtool is willing to use shell functions, then there could be very little overhead caused by support for every tag being in configure. However, it is true that if libtool is embedded in a package, the package authors know in advance which languages are required so they should be able to reduce the support provided by configure. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 07:43:52PM +0200, Alexandre Duret-Lutz wrote:
Albert Chin [EMAIL PROTECTED] writes:
[...]
| --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
| +++ libtool.m4 2003-06-03 10:22:57.667598339 -0500
[...]
| +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
| + [AC_LIBTOOL_TAGS([C C++ F77])])
Since the tag for C++ is called CXX and there is no tag for C,
it would seem more natural to read
AC_LIBTOOL_TAGS([CXX F77])
I think Bob's suggestion of AC_LIBTOOL_LANGUAGES is better if
you really want to pass language names as arguments.
Ah, ok. I'll ditch C++ and make CXX the tag name.
BTW, should we have a `C' tag and make it a NOOP or should we report
an invalid tag name for it? I hope libtool will eventually have a `C'
tag. The code before reports an error to adhere to current libtool
behavior.
[...]
| + [m4_if(_LT_TAG, C, ,
| + [m4_if(_LT_TAG, C++,
[...]
| + [m4_if(_LT_TAG, F77,
[...]
| + [m4_if(_LT_TAG, GCJ,
[...]
| + [m4_if(_LT_TAG, RC,
[...]
| + m4_errprintn(m4_location[: error: invalid tag name:
]_LT_TAG)
Maybe this can be simplified to something around the lines of
m4_case([_LT_TAG],
[C], ,
[CXX], [...],
[F77], [...],
[GCJ], [...],
[RC], [...],
[m4_fatal([unsupported tag name: ]_LT_TAG)])
Cool. I didn't see this. I've attached the latest version of the
patch. I'd like to hear from Robert before adding docs and submitting
a formal patch.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
--- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
+++ libtool.m4 2003-06-03 13:58:38.856989000 -0500
@@ -39,35 +39,7 @@
# ---
AC_DEFUN([AC_PROG_LIBTOOL],
[AC_REQUIRE([_AC_PROG_LIBTOOL])dnl
-dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
-dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX.
- AC_PROVIDE_IFELSE([AC_PROG_CXX],
-[AC_LIBTOOL_CXX],
-[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
- ])])
-dnl And a similar setup for Fortran 77 support
- AC_PROVIDE_IFELSE([AC_PROG_F77],
-[AC_LIBTOOL_F77],
-[define([AC_PROG_F77], defn([AC_PROG_F77])[AC_LIBTOOL_F77
-])])
-
-dnl Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
-dnl If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
-dnl AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
- AC_PROVIDE_IFELSE([AC_PROG_GCJ],
-[AC_LIBTOOL_GCJ],
-[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [AC_PROVIDE_IFELSE([LT_AC_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [ifdef([AC_PROG_GCJ],
-[define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([A][M_PROG_GCJ],
-[define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([LT_AC_PROG_GCJ],
-[define([LT_AC_PROG_GCJ],
- defn([LT_AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])])])
-])])# AC_PROG_LIBTOOL
+]) # AC_PROG_LIBTOOL
# _AC_PROG_LIBTOOL
@@ -226,9 +198,8 @@
test -z $pic_mode pic_mode=default
# Use C for the default configuration in the libtool script
-tagname=
AC_LIBTOOL_LANG_C_CONFIG
-_LT_AC_TAGCONFIG
+_LT_AC_TAG_CONFIG
])# AC_LIBTOOL_SETUP
@@ -1608,15 +1579,29 @@
])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
-# _LT_AC_TAGCONFIG
+# AC_LIBTOOL_TAGS
+# ---
+# tags to enable
+AC_DEFUN([AC_LIBTOOL_TAGS],
+[m4_define([_LT_TAGS],[$1])
+]) # AC_LIBTOOL_TAGS
+
+# _LT_AC_TAG_CHECK
#
-AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
-[AC_HELP_STRING([--with-tags@:@=TAGS@:@],
-[include additional configurations @:@automatic@:@])],
-[tagnames=$withval])
+AC_DEFUN([_LT_AC_TAG_CHECK],
+[m4_ifdef([_LT_TAG_]$1,
+ [m4_errprintn(m4_location[: error: duplicate tag: ]$1)
+ m4_exit(1)],
+ [m4_define([_LT_TAG_]$1, [])])
+]) # _LT_AC_TAG_CHECK
+
+# _LT_AC_TAG_CONFIG
+# -
+AC_DEFUN([_LT_AC_TAG_CONFIG],
+[AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
+ [AC_LIBTOOL_TAGS([CXX F77 GCJ RC])])
-if test -f $ltmain test -n $tagnames; then
+if test -f $ltmain; then
if test ! -f ${ofile}; then
AC_MSG_WARN([output file `$ofile' does not exist])
fi
@@ -1634,66 +1619,33 @@
# Note that this assumes the entire list is on one line.
available_tags=`grep ^available_tags= ${ofile} | $SED -e
's/available_tags=\(.*$\)/\1/' -e 's/\//g'`
- lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
- for tagname in $tagnames; do
-IFS=$lt_save_ifs
-# Check whether tagname contains only valid characters
-case `$echo X$tagname | $Xsed -e
's:[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]::g'` in
-) ;;
-*) AC_MSG_ERROR([invalid tag name: $tagname])
- ;;
-esac
-
-if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$ ${ofile} /dev/null
-then
- AC_MSG_ERROR([tag name \$tagname\ already exists])
-
1.5 automatically generating C++, F77 tags
It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is called? If not, what does it mean because the C++ tag is *always* being created? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is called? If not, what does it mean because the C++ tag is *always* being created? It looks to me like it is simply trying to ensure a proper execution order of AC_PROG_CXX vs AC_LIBTOOL_CXX. AC_LIBTOOL_CXX is run after AC_PROG_CXX and can be run immediately if AC_PROG_CXX has already been run. The default for libtool is to attempt to configure all tags. This is reasonable for a stand-alone libtool, but is not very reasonable for an embedded libtool. That is why we still need the macro you proposed which allows the user to tell libtool which language tags to configure. Package configure scripts would then need to incoporate the macro in order to limit the tags which get configured. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. does generate the C++ and F77 tags mean care whether or not the C++ preprocessor is acceptable? the latest Apache source tarball was prepared with libtool 1.5, and somebody with an unacceptable C++ prepreprocessor (which means nothing to Apache) couldn't build, though they'd been able to build prior release ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is called? If not, what does it mean because the C++ tag is *always* being created? It looks to me like it is simply trying to ensure a proper execution order of AC_PROG_CXX vs AC_LIBTOOL_CXX. AC_LIBTOOL_CXX is run after AC_PROG_CXX and can be run immediately if AC_PROG_CXX has already been run. The default for libtool is to attempt to configure all tags. This is reasonable for a stand-alone libtool, but is not very reasonable for an embedded libtool. That is why we still need the macro you proposed which allows the user to tell libtool which language tags to configure. Package configure scripts would then need to incoporate the macro in order to limit the tags which get configured. I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* if AC_PROG_CXX is called. Can autoconf do this? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Mon, 2 Jun 2003, Jeff Trawick wrote: Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. does generate the C++ and F77 tags mean care whether or not the C++ preprocessor is acceptable? the latest Apache source tarball was prepared with libtool 1.5, and somebody with an unacceptable C++ prepreprocessor (which means nothing to Apache) couldn't build, though they'd been able to build prior release I have noticed this myself. Apparently a standard Autoconf test is used to test the C++ cpp, and if the test fails, configure exits with an error. This may be an acceptable approach for C, but it is not a friendly approach when testing C++, which may not be used by the package, or may be used for an optional component. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert == Albert Chin [EMAIL PROTECTED] writes: Albert On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) [...] Albert I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* Albert if AC_PROG_CXX is called. Can autoconf do this? Automake setups its dependency tracking code for various languages with code similar to the above. Actually, the above would work if Libtool was not running expanding AC_PROG_CXX itself! (This happens when AC_LIBTOOL_LANG_CXX_CONFIG is expanded in _LT_AC_TAGCONFIG.) As I see it, the only way to achieve what you want would be to rewrite the `case $tagname' switch from _LT_AC_TAGCONFIG in plain M4 (instead of shell). This way you can ensure that AC_LIBTOOL_LANG_CXX_CONFIG is expanded only if AC_PROG_CXX has been called first. Likewise for other languages. However I don't think you can do this and still allow AC_PROC_CXX to be called after AC_PROG_LIBTOOL. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 01:08:17AM +0200, Alexandre Duret-Lutz wrote: Albert == Albert Chin [EMAIL PROTECTED] writes: Albert On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) [...] Albert I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* Albert if AC_PROG_CXX is called. Can autoconf do this? Automake setups its dependency tracking code for various languages with code similar to the above. Actually, the above would work if Libtool was not running expanding AC_PROG_CXX itself! (This happens when AC_LIBTOOL_LANG_CXX_CONFIG is expanded in _LT_AC_TAGCONFIG.) As I see it, the only way to achieve what you want would be to rewrite the `case $tagname' switch from _LT_AC_TAGCONFIG in plain M4 (instead of shell). This way you can ensure that AC_LIBTOOL_LANG_CXX_CONFIG is expanded only if AC_PROG_CXX has been called first. Likewise for other languages. However I don't think you can do this and still allow AC_PROC_CXX to be called after AC_PROG_LIBTOOL. I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert Chin wrote: I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? Reading through the thread, AC_REQUIRE kept coming to my mind, so no I don't see a problem. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
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. Maybe this could be changed as follows: - if any of AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ are called before AC_PROG_LIBTOOL, define the tags only for those which are called. (I think there is no tag for CC, but if only AC_PROG_CC is called that would just means that CXX, F77, and GCJ are not wanted.) - if none of these macros is called before AC_PROG_LIBTOOL, assume they might be called latter and define all tags, as in the current implementation. See this as backward compatibility. Also, this would allow one to configure Libtool to use some languages and ignore other. E.g., # I only use Libtool with C programs, I don't need it for C++. ... AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_CXX ... -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
