Re: Tru64/OSF: BIN_SH revisited
Hello, 0a) Revert the change to set BIN_SH in Autoconf, [...] IMHO this is a very good idea. First, BIN_SH is set in macro AS_BOURNE_COMPATIBLE, but it doesn't belong there: this macro contains things like set -o posix, which i) have an immediate effect inside the current instance ii) are not inhereted in subsequent calls to the shell (Because of (ii), AS_BOURNE_COMPATIBLE is called from _AS_RUN.) Second, if this change 0b) Additionally, prepend /usr/bin/posix/ to the path walk of _AS_DETECT_BETTER_SHELL, [...] make things work on OSF, then the BIN_SH assignment becomes redundant cruft, right? We shall remove it now, before is is conserved by a release. (If the problem re-appears when 2.60 will be widely used, we can then add BIN_SH to the right place (the detect better shell stuff), and with a comment explaining the situation where it was necessary.) Does this sound convincing? Moreover, I think that the line DUALCASE=1; export DUALCASE doesn't belong to AS_BOURNE_COMPATIBLE either, the reason is the same as above; I think it shall go to AS_SHELL_SANITIZE. These two changes would make the following patch; OK to commit? Have a nice day, Stepan 2006-03-17 Stepan Kasal [EMAIL PROTECTED] * lib/m4sugar/m4sh.m4 (AS_BOURNE_COMPATIBLE): Removed BIN_SH=xpg4, moved DUALCASE=1 ... (AS_SHELL_SANITIZE): ... here. Index: lib/m4sugar/m4sh.m4 === RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v retrieving revision 1.162 diff -u -r1.162 m4sh.m4 --- lib/m4sugar/m4sh.m4 16 Mar 2006 13:33:18 - 1.162 +++ lib/m4sugar/m4sh.m4 17 Mar 2006 15:20:12 - @@ -172,8 +172,6 @@ else case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac fi -BIN_SH=xpg4; export BIN_SH # for Tru64 -DUALCASE=1; export DUALCASE # for MKS sh ]) @@ -320,6 +318,7 @@ ## - ## AS_BOURNE_COMPATIBLE +DUALCASE=1; export DUALCASE # for MKS sh # PATH needs CR _AS_CR_PREPARE
Re: Tru64/OSF: BIN_SH revisited
Hello,
On Fri, Mar 17, 2006 at 11:20:49AM -0800, Paul Eggert wrote:
Yes, except you need to modify the Autoconf documentation accordingly.
I checked in the version attached to this mail.
Stepan
2006-03-17 Stepan Kasal [EMAIL PROTECTED]
* lib/m4sugar/m4sh.m4 (AS_BOURNE_COMPATIBLE): Removed BIN_SH=xpg4,
moved DUALCASE=1 ...
(AS_SHELL_SANITIZE): ... here.
* doc/autoconf.texi (Special Shell Variables) BIN_SH: Do not say
that it is set.
Index: lib/m4sugar/m4sh.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v
retrieving revision 1.162
diff -u -r1.162 m4sh.m4
--- lib/m4sugar/m4sh.m4 16 Mar 2006 13:33:18 - 1.162
+++ lib/m4sugar/m4sh.m4 17 Mar 2006 15:20:12 -
@@ -172,8 +172,6 @@
else
case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac
fi
-BIN_SH=xpg4; export BIN_SH # for Tru64
-DUALCASE=1; export DUALCASE # for MKS sh
])
@@ -320,6 +318,7 @@
## - ##
AS_BOURNE_COMPATIBLE
+DUALCASE=1; export DUALCASE # for MKS sh
# PATH needs CR
_AS_CR_PREPARE
Index: doc//autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.967
diff -u -r1.967 autoconf.texi
--- doc/autoconf.texi 17 Mar 2006 03:59:05 - 1.967
+++ doc/autoconf.texi 17 Mar 2006 17:19:17 -
@@ -11091,7 +11091,6 @@
@evindex BIN_SH
In Tru64, if @env{BIN_SH} is set to @code{xpg4}, subsidiary invocations of
the standard shell conform to Posix.
-Autoconf-generated scripts export this variable when they start up.
@item CDPATH
@evindex CDPATH
SP2NL cleanup
Hello,
attached please find a patch, which changes the check for EBCDIC.
1) I added a comment which explains why \n isn't portable enough.
2) space is space, no need to use \040
3) Change the logic, so that it potentially works even for other
charsets.
Stepan Kasal
2005-08-16 Stepan Kasal [EMAIL PROTECTED]
* config/general.m4sh (SP2NL, NL2SP): Simplify.
Index: config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/general.m4sh,v
retrieving revision 1.18
diff -u -r1.18 general.m4sh
--- config/general.m4sh 5 Jun 2005 17:34:17 - 1.18
+++ config/general.m4sh 16 Aug 2005 13:26:48 -
@@ -106,14 +106,15 @@
s/\([[^\\]]\(''''''\)*''''\)\$/\1\\$/g'
# test EBCDIC or ASCII
-case `$ECHO A|tr A '\301'` in
- A) # EBCDIC based system
- SP2NL=tr '\100' '\n'
- NL2SP=tr '\r\n' '\100\100'
+case `$ECHO X|tr X '\101'` in
+ A) # ASCII based system
+# '\n' is not interpreted correctly by Solaris 8 /usr/ucb/tr
+ SP2NL=tr ' ' '\012'
+ NL2SP=tr '\015\012' ' '
;;
- *) # Assume ASCII based system
- SP2NL=tr '\040' '\012'
- NL2SP=tr '\015\012' '\040\040'
+ *) # EBCDIC based system
+ SP2NL=tr ' ' '\n'
+ NL2SP=tr '\r\n' ' '
;;
esac
Re: SP2NL cleanup
Hello Ralf,
thanks for testing my patch.
On Tue, Aug 16, 2005 at 04:32:50PM +0200, Ralf Wildenhues wrote:
3) Change the logic, so that it potentially works even for other
charsets.
Good idea.
... but cannot be fully implemented without od -x or some such. :-(
For now, I returned to \100 in EBCDIC version.
Here is a patch with fixes for the problems you pointed out.
Stepan
2005-08-16 Stepan Kasal [EMAIL PROTECTED]
* config/general.m4sh (SP2NL, NL2SP): Simplify.
Index: config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/general.m4sh,v
retrieving revision 1.18
diff -u -r1.18 general.m4sh
--- config/general.m4sh 5 Jun 2005 17:34:17 - 1.18
+++ config/general.m4sh 16 Aug 2005 15:02:49 -
@@ -106,14 +106,15 @@
s/\([[^\\]]\(''''''\)*''''\)\$/\1\\$/g'
# test EBCDIC or ASCII
-case `$ECHO A|tr A '\301'` in
- A) # EBCDIC based system
- SP2NL=tr '\100' '\n'
- NL2SP=tr '\r\n' '\100\100'
+case `echo X|tr X '\101'` in
+ A) # ASCII based system
+# \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
+ SP2NL='tr \040 \012'
+ NL2SP='tr \015\012 \040\040'
;;
- *) # Assume ASCII based system
- SP2NL=tr '\040' '\012'
- NL2SP=tr '\015\012' '\040\040'
+ *) # EBCDIC based system
+ SP2NL='tr \100 \n'
+ NL2SP='tr \r\n \100\100'
;;
esac
Re: reorganized config.status
Hello, On Sat, Aug 13, 2005 at 12:00:13AM +0200, Ralf Wildenhues wrote: Other way round. I tried to make you do the work for me and did not succeed at first. :) thank you very much. You did most of the work, so I won. I'll look at the patch soon. But two comments now, in a hurry: Hmm. But this: | AC_CONFIG_COMMANDS_PRE([dnl | m4_ifndef([AH_HEADER], [AC_CONFIG_HEADERS([config.h])]) | AC_SUBST([CONFIG_H], [AH_HEADER]) | ]) would not be correct, right? I don't see any problem. It should work. I think that AC_CONFIG_COMMANDS_PRE is the last opportunity to call AC_SUBST and AC_CONFIG_FOOS. But it is not documented, yet. Quoting 'info Autoconf Configuration\ Headers: | The `AC_CONFIG_HEADERS' macro selects this kind of output. It should | be called right after `AC_INIT'. This doesn't seem correct. As far as Autoconf is concerned, AC_CONFIG_HEADERS might be called just before AC_OUTPUT. OTOH, it's a good custom to call it at the top. Perhaps some package could test for AH_HEADER... Are you willing to prepare another patch and do these two doc enhancements? Have a nice weekend, Stepan
Re: FYI: loop in libtool m4 macros
Hi, On Mon, Jun 27, 2005 at 06:21:48PM +0200, Ralf Wildenhues wrote: ... where reasonable submit documentation patches to the Autoconf folks. m4sugar.m4 at least should have a documented API that libtool and others can use... Surely. I'm not volunteering for the documentation patches, no one is, that's the problem. ;-) a preliminary list of macros used by Libtool macros [...] not defined in autoconf.texi: Let me comment on some of them: m4_bmatch This (and m4_bregexp and m4_bpatsubst) is an unfortunate name. The intention was like this: in future versions, m4 should use ERE (Extended Reg. Expr., like in egrep), so lets rename the original ones to m4_b*, as BRE (Basic R. E., like in grep). But m4 regular expressions are not BRE, even though they use \( \) for grouping. Unfortunately, this mistake was introduced in 2.53, and since then many people read the error message ``Don't use m4_patsubst, use patsubst or m4_bpatsubst instead.'' I don't know how to get out of this confusion. Perhaps we have to leave it as it is; m4_b* will denote the traditional m4 regexp versions, and m4_* will be the ERE versions. m4_defun m4_require Why do you use these and not AC_DEFUN and AC_REQUIRE? But I agree that these should be documented, for the non-Autoconf applications of m4sugar and m4sh. All other macros you netion in the first list should be documented, including: mentioned in autoconf.texi, but not defined: m4_default not defined in autoconf.texi, but listed in m4.texi (renamed m4 builtins): m4_ifdef m4_pushdef These are documented implicitly, and in the latest CVS version they even go to the index, search for [EMAIL PROTECTED]''. So these are OK. Have a nice day, Stepan Kasal
Re: documenting m4sugar.m4 [WAS: loop in libtool m4 macros]
Hello Gary, On Tue, Jun 28, 2005 at 10:58:05AM +0100, Gary V. Vaughan wrote: In order to hide some of our internal macros from aclocal, they are defined with m4_defun. Thanks for explanation. Interesting. Since aclocal doesn't do any tracing, the following could work too: m4_copy([AC_DEFUN], [LT_DEFUN]) m4_defun and AC_REQUIRE don't play together, Well, actually they do, as the AC_* macros are just an aliases, but I see what you mean. Yet another solution might be to m4_define the macros and then use m4_expand_once. But yes, m4_defun and m4_reauire should be documented, so there is no need to change the current code. Regards, Stepan
Re: FYI: loop in libtool m4 macros
Hello, On Mon, Jun 27, 2005 at 12:08:18PM +0200, Ralf Wildenhues wrote: Applied to HEAD and branch-2-0. (Only this part, so far.) -[m4_if([$1], [], [], - [AC_FOREACH([_LT_Option], [$1], +[AC_FOREACH([_LT_Option], [$1], thanks. When you are at it, I also propose the patch attached below. The reason is that AC_FOREACH will soon become obsolete. Paul Eggert agreed: http://lists.gnu.org/archive/html/autoconf-patches/2005-05/msg00082.html (I haven't yet found time to finish and commit that patch.) The problem with AC_FOREACH is that it encourages the wrong convention. AC_FOREACH was never documented, so there is no problem if you replace it by three other undocumented macros. ;-) Have a nice day, Stepan 2005-06-27 Stepan Kasal [EMAIL PROTECTED] * m4/ltoptions.m4 (_LT_UNLESS_OPTIONS, _LT_SET_OPTIONS): Replace AC_FOREACH by a combination of m4_foreach/m4_split/m4_normalize. Index: m4/ltoptions.m4 === RCS file: /cvsroot/libtool/libtool/m4/ltoptions.m4,v retrieving revision 1.12 diff -u -r1.12 ltoptions.m4 --- m4/ltoptions.m4 27 Jun 2005 10:06:31 - 1.12 +++ m4/ltoptions.m4 27 Jun 2005 10:19:31 - @@ -36,7 +36,7 @@ # --- # Execute IF-NOT-SET if all OPTIONS are not set. m4_define([_LT_UNLESS_OPTIONS], -[AC_FOREACH([_LT_Option], [$1], +[m4_foreach([_LT_Option], m4_split(m4_normalize([$1])), [m4_ifdef(_LT_MANGLE_OPTION(_LT_Option), [m4_define([$0_found])])])[]dnl m4_ifdef([$0_found], [m4_undefine([$0_found])], [$2 @@ -51,7 +51,7 @@ # dispatch to that macro; otherwise complain about the unknown option # and exit. m4_define([_LT_SET_OPTIONS], -[AC_FOREACH([_LT_Option], [$1], +[m4_foreach([_LT_Option], m4_split(m4_normalize([$1])), [_LT_SET_OPTION(_LT_Option) m4_ifdef(_LT_MANGLE_DEFUN(_LT_Option), _LT_MANGLE_DEFUN(_LT_Option),
Re: FYI: loop in libtool m4 macros
Hi Ralf, On Mon, Jun 27, 2005 at 04:55:18PM +0200, Ralf Wildenhues wrote: So I propose the following patch. I agree, and have committed it to HEAD and branch-2-0. thank you for committing this patch. (And also the other one I posted today.) Stepan
