coreutils' parallel make distcheck now fails

2009-04-10 Thread Jim Meyering
On a quad-core system, building make -j7 distcheck fails consistently like this: (note the parallel builds of rmdir.o) CC nohup.o CC readlink.o CC rm.o CC rmdir.o make[3]: Entering directory `/c/coreutils/src' CC readlink.o CC stat.o AR libver.a

Re: coreutils' parallel make distcheck now fails

2009-04-10 Thread Jim Meyering
Jim Meyering wrote: On a quad-core system, building make -j7 distcheck fails consistently like this: (note the parallel builds of rmdir.o) Oh! I left out an important detail. This is using automake built from up-to-the-minute next.

Re: coreutils' parallel make distcheck now fails

2009-04-10 Thread Ralf Wildenhues
Hi Jim, thanks for the report. * Jim Meyering wrote on Fri, Apr 10, 2009 at 02:07:53PM CEST: On a quad-core system, building make -j7 distcheck fails consistently like this: (note the parallel builds of rmdir.o) CC nohup.o CC readlink.o CC rm.o CC rmdir.o

Re: coreutils' parallel make distcheck now fails

2009-04-10 Thread Jim Meyering
Ralf Wildenhues wrote: * Jim Meyering wrote on Fri, Apr 10, 2009 at 02:07:53PM CEST: On a quad-core system, building make -j7 distcheck fails consistently like this: (note the parallel builds of rmdir.o) CC nohup.o CC readlink.o CC rm.o CC rmdir.o make[3]:

Re: coreutils' parallel make distcheck now fails

2009-04-10 Thread Ralf Wildenhues
* Jim Meyering wrote on Fri, Apr 10, 2009 at 02:51:08PM CEST: 2009-04-10 Ralf Wildenhues ralf.wildenh...@gmx.de Fix parallel distcheck failure. * maint.mk (ALL_RECURSIVE_TARGETS): Add patch-check, check-AUTHORS, maintainer-distcheck, vc-dist, taint-distcheck,

parallel-tests: dependencies between tests

2009-04-10 Thread Ralf Wildenhues
Hello, another API question turned up: do we want the developer to specify dependencies between tests as foo.log: bar.log or as foo_log_DEPENDENCIES = bar.log There are reasons for^W^Wproblems with both: - *_DEPENDENCIES can also work when tests do not use a suffix listed in

Re: [PATCH] fix grammar in comments and documentation

2009-04-10 Thread Ralf Wildenhues
Hi Jim, * Jim Meyering wrote on Fri, Apr 10, 2009 at 12:54:14PM CEST: idly searched for grammar errors with this git grep '\a [iouea]' |grep -vE 'a (use|one|uni|usage)' found a few: From 44000e4d8890bf2bdcdfe448b035836fda36b5d7 Mon Sep 17 00:00:00 2001 From: Jim Meyering

Re: aclocal problems

2009-04-10 Thread Ralf Wildenhues
http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 Hi Eric, John, * John Calcote wrote on Sat, Apr 04, 2009 at 06:55:46AM CEST: On 4/3/2009 5:31 PM, Ralf Wildenhues wrote: * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3

Re: aclocal problems

2009-04-10 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 I'd call it a documentation bug at this point. (Eric - comments?) Sorry for missing this thread; I tend not to

Re: aclocal problems

2009-04-10 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 Hi Eric, John, * John Calcote wrote on Sat, Apr 04, 2009 at 06:55:46AM CEST: On 4/3/2009 5:31 PM, Ralf

Re: aclocal problems

2009-04-10 Thread Ralf Wildenhues
* Eric Blake wrote on Fri, Apr 10, 2009 at 02:12:10PM CEST: According to Ralf Wildenhues on 4/10/2009 12:32 AM: http://thread.gmane.org/gmane.comp.sysutils.automake.general/10429/focus=10431 Good point. Public third-party macros should be AC_DEFUNed for this reason. OK to apply? Yes,

Re: aclocal problems

2009-04-10 Thread John Calcote
By the way, you may be interested in seeing how I was able to use m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4): http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4

mingw compiler on cygwin, and path issues

2009-04-10 Thread Jan Engelhardt
Hi, I am currently using automake in a Windows-related project; there is a (pure) mingw compiler in c:\mingw, and cygwin is installed in c:\cygwin. Now I noticed that Makefile.in, as generated by automake, has a CYGPATH_W variable which is `echo` on Unices, and `cygpath -w` on Cygwin. The

Re: mingw compiler on cygwin, and path issues

2009-04-10 Thread Jan Engelhardt
On Friday 2009-04-10 22:19, Jan Engelhardt wrote: AM_CFLAGS = -I${abs_top_builddir}/subproject AM_LDFLAGS = -L${abs_top_builddir}/subproject This gets expanded into -I/home/User/project/subproject, but the mingw compiler of course tries to search in C:\home\user\project\subproject instead of

Re: mingw compiler on cygwin, and path issues

2009-04-10 Thread Ralf Wildenhues
Hello Jan, * Jan Engelhardt wrote on Fri, Apr 10, 2009 at 10:23:53PM CEST: Given: AM_LDFLAGS = -L../subproject foo_LDADD = -lsub For in-tree libraries always use relative paths to the .la file: foo_LDADD = ../subproject/libsub.la you can omit the AM_LDFLAGS. Does the issue remain with