Re: mdate-sh borks on uid/gid containing a space
Hello, On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote: On 29 March 2007 00:26, Ralf Wildenhues wrote: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2730/focus=2740 Eric's patch seems to indicate that line 92 needs changed, too. (I haven't tested any on w32.) I don't quite understand that myself; ISTM that having -n in $ls_command should do the job for both cases. A wild guess: Though the current situation is this (quoting Eric): $ \ls -ld / drwxrwx---+ 14 eblake Users 0 Feb 2 07:58 / $ \ls -lLd doc/m4.texinfo -rw-r--r-- 1 eblake Domain Users 221922 Mar 1 14:50 doc/m4.texinfo it might be possible that even the user or group owner of / would have a blank it its name. (With Cygwin, one never knows.) So it is safer to use -n with ls /, too. Just guessing, I'm not a Cygwin user. Stepan Kasal
Re: mdate-sh borks on uid/gid containing a space
Hello again, On Thu, Mar 29, 2007 at 04:12:11PM +0100, Dave Korn wrote: On 29 March 2007 15:38, Stepan Kasal wrote: On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote: On 29 March 2007 00:26, Ralf Wildenhues wrote: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2730/focus=2740 Eric's patch seems to indicate that line 92 needs changed, too. [...] So it is safer to use -n with ls /, too. Umm, yes, that's true, but not relevant; what I was pointing out is that the -n gets added to the $ls_command variable, so it would already be included in the command invoked on line 92, and if you take a second look at the patch, you'll notice that the change to line 92 isn't about adding -n, it's about taking away -l and -d. I took a second look, and it did not help: @@ -89,7 +93,7 @@ # words should be skipped to get the date. # On HPUX /bin/sh, set interprets -rw-r--r-- as options, so the x below. -set x`ls -l -d /` +set x`$ls_command /` # Find which argument is the month. month= Cheers, Stepan
RE: mdate-sh borks on uid/gid containing a space
On 29 March 2007 16:27, Stepan Kasal wrote: Hello again, On Thu, Mar 29, 2007 at 04:12:11PM +0100, Dave Korn wrote: On 29 March 2007 15:38, Stepan Kasal wrote: On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote: On 29 March 2007 00:26, Ralf Wildenhues wrote: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2730/focus=2740 Eric's patch seems to indicate that line 92 needs changed, too. [...] So it is safer to use -n with ls /, too. Umm, yes, that's true, but not relevant; what I was pointing out is that the -n gets added to the $ls_command variable, so it would already be included in the command invoked on line 92, and if you take a second look at the patch, you'll notice that the change to line 92 isn't about adding -n, it's about taking away -l and -d. I took a second look, and it did not help: @@ -89,7 +93,7 @@ # words should be skipped to get the date. # On HPUX /bin/sh, set interprets -rw-r--r-- as options, so the x below. -set x`ls -l -d /` +set x`$ls_command /` Gah, I overlooked that the original version wasn't using ls_command in the first place. cheers, DaveK -- Can't think of a witty .sigline today
Re: no .deps directory generated
* Ralf Wildenhues wrote on Mon, Jan 08, 2007 at 08:46:06PM CET: * David Byron wrote on Mon, Jan 08, 2007 at 07:40:02PM CET: [...] AC_CONFIG_FILES([Makefile util/Makefile util/tests/Makefile:config/cppunit.mk.in:util/tests/Makefile.in testmain/Makefile]) Darn, this looks like a regression of 1.10 over 1.9.6, due to the sed 10q in m4/depout.m4: because cppunit.mk is longer than 10 lines, it won't get to the generated by automake line any more. I've applied this patch to HEAD and branch-1-10 now, and added David to THANKS. Cheers, Ralf * m4/depout.m4 (_AM_OUTPUT_DEPENDENCY_COMMANDS): Again search the whole file, but use sed to reduce the line length. Fixes 1.10 regression. Report by David Byron. * THANKS, NEWS: Update. Index: NEWS === RCS file: /cvs/automake/automake/NEWS,v retrieving revision 1.324 diff -u -r1.324 NEWS --- NEWS28 Mar 2007 23:08:05 - 1.324 +++ NEWS29 Mar 2007 22:39:30 - @@ -20,6 +20,11 @@ * Long standing bugs: - Fix aix dependency tracking for libtool objects. + +* Bugs introduced by 1.10: + + - Fix output of dummy dependency files in presence of post-processed +Makefile.in's again, but also cope with long lines. New in 1.10: Index: m4/depout.m4 === RCS file: /cvs/automake/automake/m4/depout.m4,v retrieving revision 1.19 diff -u -r1.19 depout.m4 --- m4/depout.m46 Jun 2006 20:39:22 - 1.19 +++ m4/depout.m429 Mar 2007 22:39:31 - @@ -22,7 +22,7 @@ # each Makefile.in and add a new line on top of each file to say so. # Grep'ing the whole file is not good either: AIX grep has a line # limit of 2048, but all sed's we know have understand at least 4000. - if sed 10q $mf | grep '^#.*generated by automake' /dev/null 21; then + if sed -n 's,^#.*generated by automake.*,X,p' $mf | grep X /dev/null 21; then dirpart=`AS_DIRNAME($mf)` else continue
Re: undefined macro
Hello John, Jason, all, * John Darrington wrote on Thu, Mar 29, 2007 at 01:52:12AM CEST: [ CCing to automake@gnu.org as this is an automake issue ] Thanks. I had similar problems after upgrading to automake-1.10, which (because it wasn't available in Debian etch) I installed in /usr/local whereas all the m4 macros were in /usr. This is an issue, but AFAICS it's not the same one as what Jason is experiencing. The solution I used was to create a file /usr/local/share/aclocal/dirlist containing the single line /usr/share/aclocal I don't think this solution is particularly neat, but it worked for me. For your issue (letting aclocal know about third-party m4 files installed below a different $prefix), your solution is the best one currently available. See at the end for a solution to Jason's issue. On Wed, Mar 28, 2007 at 04:08:30PM -0400, Jason Stover wrote: make -f Smake is failing to expand AM_INTL_SUBDIR. I've been struggling with this problem for a while now. My lack of understanding of aclocal and autoconf is hindering progress. So tell me if I have this straight: 1. aclocal should copy the contents of m4/*.m4 and gl/m4/*.m4 into configure.ac. aclocal creates the file aclocal.m4. It looks at configure.ac and all kinds of other files and figures what text is needed in the output file. Then all macro files needed are copied in there (for macros found in installed files) or links to them by way of m4_include() (for macros found in files with a non-absolute path). 2. autoconf should read the macros defined in configure.ac, run m4 on them, and place the results in configure. autoconf reads configure.ac, aclocal.m4, m4_include()d files (and a couple more), and expands macros recursively. [...] aclocal -I m4 -I gl/m4 autoconf configure.ac:26: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd m4/gettext.m4:362: AM_GNU_GETTEXT is expanded from... configure.ac:26: the top level configure:20777: error: possibly undefined macro: AM_INTL_SUBDIR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. *** Error code 1 ...the problem is that I can see the macro defined in the m4 directory: $ grep AM_INTL_SUBDIR m4/*.m4 m4/gettext.m4:AC_REQUIRE([AM_INTL_SUBDIR])dnl m4/intl.m4:AC_DEFUN([AM_INTL_SUBDIR], ...so it looks like aclocal isn't including some necessary information in configure.ac. Is that right? [...] A few details that might be relevant: I recently upgraded to the latest version of automake, and auto*, and aclocal. My system has BSD m4 in /usr/bin, and GNU m4 1.4.3 in /usr/local/bin. I think you need a newer M4. 1.4.9 is the current one, but I think the fix you need is in 1.4.5. Cheers, Ralf
Re: shell pwd: non-POSIX variable name ??
Hi, On Thu, Mar 29, 2007 at 02:25:31PM +0200, Jules Colding posted an Automake question to the Autoconf list. (Understandable mistake, of course.) I suppose the question can be deduced from my answer. :-) What is the recommended and portable way of doing what I do above to avoid the warnings and to be nice to automake? OBJS= $(patsubst %.c,%.o,$(STUB_SRC)) this can ce written portably as: OBJS = $(STUB_SRC:.c=.o) EXTRA_DIST = $(pkgconfig_DATA:-$(LIBBRUTUS_CURRENT).$(LIBBRUTUS_REVISION).pc=.pc.in) It is not portable to use immersed variable expansion. But if LIBBRUTUS_CURRENT and LIBBRUTUS_REVISION are AC_SUBSTed variables, you can use the @...@ form here: EXTRA_DIST = $(pkgconfig_DATA:[EMAIL PROTECTED]@[EMAIL PROTECTED]@.pc=.pc.in) CWD = $(shell pwd) BARE_NAMES = $(notdir $(IDL_FILES)) LOCAL_IDL_FILES = $(addprefix $(CWD)/,$(BARE_NAMES)) I do not know any easy way to replace these. You would have to change the logic of the makefile. Needless to say that all of this worked without any warnings prior to automake-1.10. To switch these warnings off for a particular Makefile.am, use AUTOMAKE_OPTIONS = -Wno-portability To switch them off glibally, use AM_INIT_AUTOMAKE([-Wno-portability]) in your configure.ac. For your information, I found this comment in Automake 1.9.5: (and I believe is was there since 1.7 till 1.9.6) # FIXME: 'portability' warnings are currently disabled by default. # Eventually we want to turn them on in GNU and GNITS modes, but # we don't do this yet in Automake 1.7 to help the 1.6/1.7 # transition. # # Indeed there would be only two ways to get rid of these new # warnings: # 1. adjusting Makefile.am # This is not always easy (or wanted). Consider %-rules or # $(function args) variables. # 2. using -Wno-portability # This means there is no way to have the same Makefile.am # working both with Automake 1.6 and 1.7 (since 1.6 does not # understand -Wno-portability). # # In Automake 1.8 (or whatever it is called) we can turn these # warnings on, since -Wno-portability will not be an issue for # the 1.7/1.8 transition. Have a nice day, Stepan Kasal
Re: shell pwd: non-POSIX variable name ??
* Stepan Kasal wrote on Thu, Mar 29, 2007 at 04:19:33PM CEST: For your information, I found this comment in Automake 1.9.5: (and I believe is was there since 1.7 till 1.9.6) [...] Needless to say that all of this worked without any warnings prior to automake-1.10. Yes, and Automake 1.10's NEWS file contains the missing bit here: | - `-Wportability' has finally been turned on by default for `gnu' and |`gnits' strictness. This means, automake will complain about %-rules |or $(GNU Make functions) unless you switch to `foreign' strictness or |use `-Wno-portability'. Cheers, Ralf
Re: Lost in automatic dependencies
On Wed, Mar 28, 2007 at 11:45:47PM +0200, Ralf Wildenhues [EMAIL PROTECTED] wrote: so please enclose AM_INIT_AUTOMAKE in `set -x', `set +x' in configure.ac, add `set -x' as second line to depcomp, run autoconf and configure. Send output. Here it is. dep-problem.txt.gz Description: Binary data
Re: undefined macro
On Wed, Mar 28, 2007 at 04:08:30PM -0400, Jason Stover wrote: make -f Smake is failing to expand AM_INTL_SUBDIR. I've been struggling with this problem for a while now. My lack of understanding of aclocal and autoconf is hindering progress. Jason kindly gave me a login on the system that was exhibiting the problem. I think I tracked down the problem. My analysis follows. AM_GNU_GETTEXT does the following, in part: define([gt_included_intl], ifelse([$1], [external], ifdef([AM_GNU_GETTEXT_][INTL_SUBDIR], [yes], [no]), [yes])) ... ifelse(gt_included_intl, yes, [ AC_REQUIRE([AM_INTL_SUBDIR])dnl ]) Thus, if AM_GNU_GETTEXT is passed external as its first argument, and AM_GNU_GETTEXT_INTL_SUBDIR is defined, then gt_included_intl will be set to yes and AM_INTL_SUBDIR will be invoked. Nothing in PSPP causes AM_GNU_GETTEXT_INTL_SUBDIR to be defined, so AM_INTL_SUBDIR should not be invoked. Yet some testing revealed that the ifdef was taking the yes path. I eventually figured out that the trace on AM_GNU_GETTEXT_INTL_SUBDIR was causing m4 to think that it was defined. It turns out that GNU m4 1.4.3 believes that any macro being traced is defined: $ gm4 --version GNU M4 1.4.3 Written by Rene' Seindal. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ which gm4 /usr/local/bin/gm4 $ uname -a OpenBSD math.gcsu.edu 4.0 GENERIC#1 i386 $ cat foo.m4 ifdef(`foo',`yes',`no') $ gm4 foo.m4 no $ gm4 --trace=foo foo.m4 yes But m4 1.4.8 does not share this belief: $ m4 --version GNU M4 1.4.8 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Rene' Seindal. $ which m4 /usr/bin/m4 $ uname -a Linux blp 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 GNU/Linux $ cat foo.m4 ifdef(`foo',`yes',`no') $ m4 foo.m4 no $ m4 --trace=foo foo.m4 no $ Conclusions: 1. Jason: I think you can fix the problem by upgrading to the latest version of GNU m4. 2. I don't understand why m4 behavior changed. It doesn't seem to be mentioned explicitly anywhere in NEWS. I guess it must be related to this item for version 1.4.4b, though: * Tracing a macro by name is now persistent, even if the macro is subsequently undefined or redefined. The traceon and traceoff macros no longer warn about undefined symbols. This solves a crash when using indir on an undefined macro traced with the -t option, as well as an incorrect result of ifdef. Furthermore, tracing is no longer transferred with builtins, solving the bug of m4 -tm4_eval failing to give trace output on the input define(`m4_eval',defn(`eval'))m4_eval(1). The new behavior, where tracing a macro doesn't make it appear to be defined, is certainly better, though. 3. It seems that Autoconf should more strongly recommend, or even test for and require, a recent version of m4, since older versions can cause such bizarre, difficult-to-debug problems. -- Ben Pfaff [EMAIL PROTECTED]
Re: undefined macro
Hello Ben, * [EMAIL PROTECTED] wrote on Thu, Mar 29, 2007 at 05:37:20AM CEST: Jason kindly gave me a login on the system that was exhibiting the problem. I think I tracked down the problem. My analysis follows. I'm sorry that you had to do it for this known bug. I guess I should have written more clearly in my earlier response. Conclusions: 1. Jason: I think you can fix the problem by upgrading to the latest version of GNU m4. ACK. 2. I don't understand why m4 behavior changed. It doesn't seem to be mentioned explicitly anywhere in NEWS. I guess it must be related to this item for version 1.4.4b, though: Yes. 3. It seems that Autoconf should more strongly recommend, or even test for and require, a recent version of m4, since older versions can cause such bizarre, difficult-to-debug problems. Yes, in response to a couple of reports about this bug, CVS Autoconf now has this NEWS entry: | ** Autoconf now requires GNU M4 1.4.5 or later. Earlier versions of M4 have |a bug in macro tracing that interferes with the interaction between |Autoconf and Automake. GNU M4 1.4.8 or later is recommended. Apologies for any miscommunication I was part of. Cheers, Ralf
Re: Lost in automatic dependencies
* Stephane Bortzmeyer wrote on Thu, Mar 29, 2007 at 10:53:57PM CEST: On Wed, Mar 28, 2007 at 11:45:47PM +0200, Ralf Wildenhues [EMAIL PROTECTED] wrote: so please enclose AM_INIT_AUTOMAKE in `set -x', `set +x' in configure.ac, add `set -x' as second line to depcomp, run autoconf and configure. Send output. Here it is. This shows the result as loaded from the cache file (config.cache) or possibly from /usr/local/etc/config.site, but not the output of the actual tests. Please remove the cache file and rerun configure. Cheers, Ralf
Re: problem with a test that is expected to fail, on cygwin only...
[ http://lists.gnu.org/archive/html/automake-patches/2007-01/msg5.html ] * Ralf Wildenhues wrote on Thu, Jan 18, 2007 at 10:22:28PM CET: * Ed Hartnett wrote on Tue, Jan 16, 2007 at 03:17:00AM CET: I am having a problem on cygwin only. I have a test which is expected to fail. In the Makefile.am I have this: I have applied this patch now. Cheers, Ralf 2007-01-18 Ralf Wildenhues [EMAIL PROTECTED] * automake.in (handle_tests): Rewrite XFAIL_TESTS just like TESTS, appending $(EXEEXT), so that matching continues to work on w32. * NEWS: Mention this. * doc/automake.texi (EXEEXT, Extending): Update. * tests/check7.test: New test. * tests/Makefile.am: Adjust. Bug report by Ed Hartnett.
