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
LIBTOOL TAG CONFIG tag header
Why do we create the libtool tag header/footer like so: BEGIN LIBTOOL TAG CONFIG: $tagname END LIBTOOL TAG CONFIG: $tagname Why not use $1: @@ -3911,7 +3953,7 @@ available_tags= # ### BEGIN LIBTOOL CONFIG], -[# ### BEGIN LIBTOOL TAG CONFIG: $tagname]) +[# ### BEGIN LIBTOOL TAG CONFIG: $1]) # Libtool was configured on host `(hostname || uname -n) 2/dev/null | sed 1q`: @@ -4207,7 +4249,7 @@ ifelse([$1],[], [# ### END LIBTOOL CONFIG], -[# ### END LIBTOOL TAG CONFIG: $tagname]) +[# ### END LIBTOOL TAG CONFIG: $1]) __EOF__ -- 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])
-
Re: ordering optional libraries
On Tue, Jun 03, 2003 at 10:31:02PM -0500, Robert Boehne wrote: Marcus, If you have to depend on weak symbols, your platform list will be small enough that Libtool will be mostly a burden. I would advise you to craft your own make/configure magic instead. Well, yeah. Personally, I consider to be libtool the tool of choice for building libraries, regardless of my target, and thus of course want it to not be limited to the common denominator among all systems. After all, as the libtool manual states, libtool does not only encapsulates platform-specific dependencies, but also the user interface. For me often the latter is much more important than the former. If I can only use libtool in the basic cases and have to use my own solution as soon as I am writing only for the GNU system and start to use advanced features, then from my perspective that is a deficit in libtool, in particular because it is a GNU package itself. In this particular case, you are right of course. As I can not limit myself to platforms which support libtool, and the weak symbol trick does not work with static linking anyway, we thus can not leave it to the user of the library to decide if it can rely on it to work automagically or not. I guess I have to build several versions of the library. However, in general, I am really hoping that I never have to hand craft my own shared library rules, and that if my target is only some particular platforms known to support weak symbols, I hope that such an addition will be considered. I am willing to leave it at that for this time :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
