bug#66352: parallel make yields "find: ���./conf*.dir���: No such file or directory" errors

On 2023-11-03 10:28:38 -0600, Karl Berry wrote: > When I want to build Automake (current Git version) with > a parallel make ("make -j12"): > > I surmise this one was caused by the same random timing failures as your > other reports, 66353 and 66354. > > A couple days ago we finally insta

bug#66354: test suite: remake-after-aclocal-m4 failure

On 2023-10-05 15:18:39 -0600, Karl Berry wrote: > Thanks. I wonder if this and aclocal-I-and-install fail consistently for > you. There is a timing issue with development automake that requires > development autoconf (for a one-character fix in autom4te). Info: > https://bugs.gnu.org/64756. Indeed

bug#55025: [PATCH] New "posix" automake option.

This patch is from https://bugs.gnu.org/55025. * lib/Automake/Options.pm: declare "posix" option. * bin/automake.in: if the "posix" option is present, add a .POSIX special target as the first non-comment line in the Makefile.in files. * NEWS: mention this. * doc/automake.texi: likewise. --- NEWS

bug#66354: test suite: remake-after-aclocal-m4 failure

Under Debian/unstable, when testing the automake Git version (80714ea0aba62f025780f432abfbab2e66f6f801), remake-after-aclocal-m4 is one of the two tests that fail. I've attached the t/remake-after-aclocal-m4.log file. -- Vincent Lefèvre - Web: 100% accessible validated

bug#66353: test suite: aclocal-I-and-install failure

Under Debian/unstable, when testing the automake Git version (80714ea0aba62f025780f432abfbab2e66f6f801), aclocal-I-and-install is one of the two tests that fail. I've attached the t/aclocal-I-and-install.log file. -- Vincent Lefèvre - Web: 100% accessible validated (X)

bug#66352: parallel make yields "find: ‘./conf*.dir’: No such file or directory" errors

When I want to build Automake (current Git version) with a parallel make ("make -j12"): MAKEINFO doc/automake-history.info GEN bin/automake GEN bin/aclocal GEN t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN doc/aclocal.1 GEN runtest GEN doc/aut

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-10-03 15:08:42 -0600, Karl Berry wrote: > Yes, Automake should either detect a ".POSIX:" in the Makefile.am > file (at least if it is the first non-comment line) and place it at > the beginning of Makefile.in, or provide an option to be used with > AM_INIT_AUTOMAKE (or AUTOM

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-10-02 15:17:13 -0600, Karl Berry wrote: > Sorry, I don't understand what you want Automake to do. > > Right now, as far as I can tell, Automake does nothing with .POSIX. It's > not mentioned in the manual nor, as far as I can grep, the code. Maybe > that's the issue, and you want a leading

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote: > Consider these two Makefiles, identical except for the presence of > the .POSIX special target: > > % cat >noposix.mk <<'EOF' > craziness: > @-false; echo hello > @false; echo hello > EOF > > % cat >posix.mk <<'EOF' > .POSIX:

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-01-14 15:12:00 -0700, Karl Berry wrote: > P.S. I note that GNU make just made an alpha release. If anyone > wants to report the purported .POSIX bug, might be a good time. I've just reported it: https://savannah.gnu.org/bugs/index.php?63667 -- Vincent Lefèvre - Web:

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote: > Does adding .POSIX: to a Makefile actually solve any real-world > portability problem with Automake generated makefiles, or is all of > this just hypothetical? For MPFR, when I initially added it, this was just in case. The real issue at that tim

bug#55025: Automake should allow one to enable POSIX make behavior

On 2023-01-13 01:19:39 -0500, Mike Frysinger wrote: > any reason we don't just define it ourselves unconditionally ? seems > like the whole point of Automake is for devs to not worry about these > kind of nitty details. Probably. Note, however, that .POSIX affects GNU "make" on a few points (the

bug#55025: Automake should allow one to enable POSIX make behavior

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html says about the target rules: .POSIX The application shall ensure that this special target is specified without prerequisites or commands. If it appears as the first non-comment line in the makefile, /make/ shall pro

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

t it is sufficient to fix the example (the explanation is just below). BTW, the second example is also incorrect. commit a639e5b51cadbaff88ca4059b4db4571c811070c Author: Vincent Lefevre Date: 2020-04-23 17:33:54 +0200 doc: fix dist-hook examples diff --git a/doc/automake.texi b/doc/a

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

On 2020-04-18 19:11:14 -0400, Nick Bowler wrote: > I guess the note about dist-hooks when packaging from a read-only srcdir > was added because of my bug report[1]. > > I have never noticed read-only _directories_ in the distdir before (I > have assumed they are always created read-write so that A

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

On 2020-04-18 15:04:08 -0600, Karl Berry wrote: > Hi Vincent, > > So, if the subdirectories may not be writable, how can the rm in the > first example work without changing the permissions first? > > [namely:] > dist-hook: > rm -rf `find $(distdir)/doc -type d -name .s

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

doc/automake.texi contains: @example EXTRA_DIST = doc dist-hook: rm -rf `find $(distdir)/doc -type d -name .svn` @end example @c The caveats described here should be documented in 'disthook.sh'. @noindent Note that t

bug#22856: "make check" can start a shell on binary data

Sorry, forget this bug report. After wondering where the problem came from exactly, I've eventually found that this is some incredible bug in dash! -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - comput

bug#22856: "make check" can start a shell on binary data

When I cross-compile for Windows and run "make check" without LOG_COMPILER=wine (by mistake), strange files appear. For instance, as a simple example with MPFR: cventin:...re/mpfr-3.1/tests> make tadd.log FAIL: tadd.exe The failure is expected, but I get: -rw-r--r-- 1491 2016-02-29 19:39:24

bug#18662: Local -L flags for "make check" appear too late under HP-UX

I reported the following bug http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9728 against libtool a few years ago, but it was said that the bug was in autoconf or automake (then, I suspect automake). I don't know whether something has been done on the automake side; I don't have access to HP-UX ma

bug#17764: autom4te version is not remembered (for maintainer mode)

I use 2 autoconf versions: $ autoconf --version autoconf (GNU Autoconf) 2.69 [...] $ $HOME/autoconf/bin/autoconf --version autoconf (GNU Autoconf) 2.69.115-251d1-dirty [...] With MPFR: $ $HOME/autoconf/bin/autoreconf $ ./configure AUTOCONF=$HOME/autoconf/bin/autoconf AUTOHEADER=$HOME/autoconf/b

bug#11007: incorrect dependency style (depmode) of tcc

I've reported the following bug on the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663705 for Automake 1.11.3. When I configure MPFR with CC=tcc, as soon as a .c file is modified or I do a "make clean", I get errors when I want to rebuild MPFR. For instance, after a "make cle

Re: library rebuilt after "make check"

[Added Paul to Cc, there's something for you.] On 2009-09-19 09:29:44 +0200, Ralf Wildenhues wrote: > Thanks. Please fix the wording on > to state that, for checking > out the project source code repo, one only needs .../svn/mpfr/trunk, and > not the co

Re: library rebuilt after "make check"

Hi Ralf, On 2009-09-18 19:15:12 +0200, Ralf Wildenhues wrote: > What system and file system is this on, which make implementation and > version, which autoconf version, do you use the parallel-tests option, > and when will mpfr.org be online again? Mac OS X (PowerPC) 10.4.11, HFS+, GNU Make 3.80,

ACDIR should be disabled by default

Hi, The ACDIR feature leads to various practical problems, such as: * Possible clash between software that installs files in ${prefix}/share/aclocal/; in particular, there isn't any namespace mechanism, it is difficult to say which file belongs to which software, and this makes debu

Re: Incorrect information in the manual about the tar-v7 option

On 2008-09-17 22:45:15 +0200, Ralf Wildenhues wrote: > * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: > > Shouldn't tar-ustar be the default instead of tar-v7? > > I'm not an expert on tar implementations and their issues, > and what would be a good

Incorrect information in the manual about the tar-v7 option

Hi, The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. This is incorrect. O

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-31 10:43:51 -0600, Bob Proulx wrote: > That was why I posted the workaround for this problem of using touch > to set all of the timestamps to the current time. I am not sure you > noticed it. I noticed it, but didn't like this workaround because of that, especially on a handheld: > If

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-31 12:19:54 +0200, Ralf Wildenhues wrote: > * Vincent Lefevre wrote on Sun, Aug 31, 2008 at 12:11:04PM CEST: > > Allow the user to choose AM_MAINTAINER_MODE's default in a clean way. > > Well, that's one of the already-mentioned workarounds, no? I mean i

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-31 06:34:44 +0200, Ralf Wildenhues wrote: > Other than the workarounds already mentioned in this thread, I don't > see what Automake can do about it. Allow the user to choose AM_MAINTAINER_MODE's default in a clean way. > Really it's the system that should be fixed. Unfortunately when

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-27 11:16:54 -0600, Bob Proulx wrote: > I think the best and easiest workaround is to set all of the file > times to the same time. Then make will consider them up to date. > > $ cd PROJECTDIR && find . -type f -exec touch -r . {} + > > But if you can't set the time on files then tha

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-27 19:17:19 +0200, Ralf Wildenhues wrote: > As in: the configure.ac author gets to decide that if the user of the > package types > ./configure > > then maintainer mode should be enabled, only if she types > ./configure --disable-maintainer-mode > > or > ./configure --enable-main

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

On 2008-08-27 18:45:24 +0200, Ralf Wildenhues wrote: > The --disable-dependency-tracking option turns off the mechanism that > updates .deps/*.Po files which contain dependencies for compiled sources > like C and C++. This has nothing to do with rebuild rules. > > You can add AM_MAINTAINER_MODE t

generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

I've generated a tarball on a Debian/unstable machine. On the Zaurus, after running ./configure --enable-assert=full --disable-shared \ --disable-dependency-tracking CC=gcc "make" wants to run "missing": zaurus:~sd/mpfr-2.3.2-rc1> =make && =make check cd . && /bin/bash /usr/mnt.rom/card/mp

Re: some clean rules don't work when some file starts with '-'

On 2008-03-21 08:24:34 +0100, Ralf Wildenhues wrote: > But you still can't pass such a file to the linker without additional > hassles. So why not use 'gcc -xc -c -o ... -'? Of course I can use it. But before seeing the error with "make clean", I didn't know this could be a problem. And such prob

Re: some clean rules don't work when some file starts with '-'

On 2008-03-21 00:24:20 +0100, Ralf Wildenhues wrote: > Hello Vincent, > > * Vincent Lefevre wrote on Thu, Mar 20, 2008 at 01:26:21PM CET: > > mostlyclean-compile: > > -rm -f *.$(OBJEXT) > > > > This results in: > > > rm -f *.o > > rm: inva

some clean rules don't work when some file starts with '-'

automake 1.10.1 generates a Makefile with: mostlyclean-compile: -rm -f *.$(OBJEXT) This results in: $ /usr/bin/make clean && echo OK [...] rm -f *.o rm: invalid option -- . Try `rm ./-.o' to remove the file `-.o'. Try `rm --help' for more information. make[1]: [mostlyclean-compile] Error

Re: Infinite loop in mdate-sh

On 2005-06-08 20:41:21 +0200, Alexandre Duret-Lutz wrote: > unset is not portable. > Can we override TIME_STYLE with some safe value? Which one? > What happens when this is set to the empty string? An empty string is incorrect: ay:~> TIME_STYLE= ls -l ls: ambiguous argument `' for `time style'