`automake -a -c -f` wrongly updates the INSTALL file

://freestdf.sourceforge.net/liblzw.php -AUTHOR: Mike Frysinger [EMAIL PROTECTED] +Installation Instructions +* ... yikes ! :) -mike

Re: make -s should cause libtool to get --silent

On Friday 05 January 2007 19:51, Reuben Thomas wrote: This is arguably a wish rather than a bug, but it's most irritating that on an autotoolized project make --silent isn't (though admittedly it's a lot quieter than without --silent). I realise there are workarounds, but they shouldn't be

Re: make -s should cause libtool to get --silent

On Friday 05 January 2007 21:00, Reuben Thomas wrote: On Fri, 5 Jan 2007, Mike Frysinger wrote: On Friday 05 January 2007 19:51, Reuben Thomas wrote: This is arguably a wish rather than a bug, but it's most irritating that on an autotoolized project make --silent isn't (though admittedly

Re: automake-1.8.5-r3 - test fails - Gentoo 2007.0

On Wednesday 16 May 2007, Ralf Wildenhues wrote: Anyway it would be helpful to see verbose test output for failures. In the above case, that would be the output of cd /var/tmp/portage/sys-devel/automake-1.8.5-r3/work/automake-1.8.5/tests env VERBOSE=yes make -e check TESTS='exdir2.test

Re: `automake -a -c -f` wrongly updates the INSTALL file

On Thursday 28 September 2006, Mike Frysinger wrote: i normally use automake-1.9.6 but i just tried out 1.9b and it appears to have the same problem automake-1.10 exhibits the problem as well ... finally spent some time digging at it for fun $ svn st INSTALL $ automake-1.9b -a -c $ svn st

Re: Problem with AM_CONDITIONAL

On Monday 21 January 2008, Santiago Capel Torres wrote: I define the AM_CONDITIONAL in 'configure.ac': CONF_HAVE_RTK=yes AM_CONDITIONAL( [COMPILE_WITH_RTK], [ test $CONF_HAVE_RTK == yes ]) test uses one =, not two and in the makefile.am: if COMPILE_WITH_RTK RTK_SUBDIR

Re: Double '/' in source path breaks compilation if done from a directory not where the Makefile.am resides

On Tuesday 25 November 2008 05:16:09 Aleksander Morgado wrote: Also, if I use $(srcdir) to mark the top level path of the sources, it won't crash. But not sure if this is the best way to have it: test_SOURCES = config.h \ $(srcdir)/src/module//test.c afaik, this is correct.

Re: Using GNU Make

On Friday 03 April 2009 20:01:15 Reuben Thomas wrote: Is there a standard way to make an autotoolised build system require GNU Make? I'm getting a bit fed up having to express everything in POSIX make when most systems now seem to have GNU Make, even where it's not installed as the default

Re: Using GNU Make

On Saturday 04 April 2009 12:35:08 Reuben Thomas wrote: On Sat, 4 Apr 2009, Ralf Wildenhues wrote: * Reuben Thomas wrote on Sat, Apr 04, 2009 at 01:44:48PM CEST: I would imagine an AC_MAKE_GNU (or somesuch) that looks at make's help output, then tries gmake (and gnumake?) if make is not GNU

Re: Using GNU Make

On Saturday 04 April 2009 14:55:01 Reuben Thomas wrote: On Sat, 4 Apr 2009, Mike Frysinger wrote: maybe use GNUmakefile.am rather than Makefile.am ? and then keep a dummy Makefile around that merely says hey sucka, GNU-make only! and/or just re- run the specified command as gmake

Re: Using GNU Make

On Monday 06 April 2009 16:32:35 Ralf Wildenhues wrote: * Reuben Thomas wrote on Sat, Apr 04, 2009 at 09:15:43PM CEST: On Sat, 4 Apr 2009, Mike Frysinger wrote: what would be cool is if automake processed some GNU makeisms in the .am - .in step. personally, i use some things like

Re: Using GNU Make

On Tuesday 07 April 2009 18:40:31 Reuben Thomas wrote: On Tue, 7 Apr 2009, Ralf Wildenhues wrote: indeed, part of any other widely used package, and with the following: In fact, gnulib already has a gnu-make module that adds a conditional which you can use to add GNU make-specific code. I

Re: aclocal directory not found error

On Thursday, July 29, 2010 01:40:24 Ralf Wildenhues wrote: * Behdad Esfahbod wrote on Thu, Jul 29, 2010 at 03:20:37AM CEST: So this tiny issue has been bugging me for years. Thought I report. Can you please make aclocal silently ignore include directories that do not exist? It bothers me

Re: aclocal directory not found error

On Thursday, July 29, 2010 02:07:35 Ralf Wildenhues wrote: * Mike Frysinger wrote on Thu, Jul 29, 2010 at 07:52:41AM CEST: On Thursday, July 29, 2010 01:40:24 Ralf Wildenhues wrote: * Behdad Esfahbod wrote on Thu, Jul 29, 2010 at 03:20:37AM CEST: So this tiny issue has been bugging me

bug#8921: side stepping automake limitations with custom dependencies

i'm working on a project (urjtag) that has yacc/lex files in it. and other files in the directory depend on the generated output from yacc/lex. so the automake file looks something like: libbsdl_la_SOURCES = \ vhdl_bison.y \ bsdl_bison.y \ bsdl.c \

bug#10473: Run automake to create config.sub without any Makefile.am

On Tuesday 10 January 2012 16:10:29 Nick Bowler wrote: On 2012-01-10 15:41 -0500, Mike Frysinger wrote: On Monday 09 January 2012 18:49:28 Eric Blake wrote: On 01/09/2012 03:46 PM, Roger Pau Monné wrote: It creates the needed files, but exits with status 1. Is there anyway

bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR

consider this simple code base: $ cat configure.ac AC_PREREQ([2.63]) AC_INIT([foo], [0]) AM_INIT_AUTOMAKE([1.11 -Wall foreign]) AC_PROG_CC LT_INIT AC_OUTPUT(Makefile) $ cat Makefile.am lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c $ touch foo.c with automake-1.11.5, everything works

bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR

On Friday 04 May 2012 03:20:10 Peter Rosin wrote: On 2012-05-04 07:25, Mike Frysinger wrote: consider this simple code base: $ cat configure.ac AC_PREREQ([2.63]) AC_INIT([foo], [0]) AM_INIT_AUTOMAKE([1.11 -Wall foreign]) AC_PROG_CC LT_INIT AC_OUTPUT(Makefile) $ cat

bug#14396: AM_CPPFLAGS not respected when using subdir-objects

i've been playing around with subdir-objects and noticed that sub-compiles don't respect AM_CPPFLAGS :(. happens with automake 1.13.1 and the latest 1.13.1d test release. also using autoconf-2.69 if it matters. $ cat configure.ac AC_INIT([pkg], [0]) AM_INIT_AUTOMAKE([subdir-objects])

bug#52256: conditional info pages don't work

On 03 Dec 2021 15:54, Karl Berry wrote: > unfortunately, automake doesn't seem to handle this situation correctly. > > Not surprising. > > ctf-spec.texi:2: unknown command `forcedError' > > Maybe you would like to look into it? It's not like I have any special > knowledge here. At

bug#29987: Problem when testing 'makeinfo' date output with 'date'

i believe this was fixed for automake-1.16.2 http://git.savannah.gnu.org/cgit/automake.git/commit/?h=c64fa5a2bdbff8874e13aa7ad179c45a5aa52f29 from NEWS: - The automake test txinfo-vtexi4.sh no longer fails when localtime and UTC cross a day boundary.

bug#31262: makefile = 1.14, when I have 1.15

On Wed, 25 Apr 2018 21:02:49 -0500, Eric Blake wrote: > But yes, it would also be nice if automake didn't bake in quite such a > version correlation between rules in a Makefile generated by an older > version of automake when coupled with rerunning a newer automake because > a Makefile.am changed.

bug#22463: c++ linker instead of c linker

On Mon, 25 Jan 2016 22:08:48 +1100, Sylvain BERTRAND wrote: > In git efl (enlightenment), the libtool library libevas.la has always a c++ > linker rule generated, even though, with some disabled options, only a c > linker > is required: Some AM_CONDITIONAL can remove all c++ source/object files

bug#11078: Mailing lists missing from the Automake's savannah page

On Fri, 23 Mar 2012 20:39:46 +0100, Stefano Lattarini wrote: > The "Automake - Mailing Lists" page on Savannah: > > > > only lists the Automake-NG mailing list, and none of the lists for > mainstream Automake. This is not good. Anyone knows right

bug#52256: conditional info pages don't work

the gdb/binutils/gcc projects don't commit info pages to the git tree. but people build them from git on old distros semi-frequently. so the tree handles things like old versions of makeinfo -- if a version is too old, then info pages aren't built. unfortunately, automake doesn't seem to handle

bug#33711: configure --host=aarch64 produces x86-64 binary

reassign 33711 autoconf thanks On 11 Dec 2018 22:07, Erik van Velzen wrote: > I compiled https://github.com/json-c/json-c using the command `sh > autogen.sh && ./configure --host=aarch64 && make`. Unexpectedly this > creates an x64 binary. > > The correct argument in my case is

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

On 11 Dec 2021 23:19, Moritz Klammler wrote: > An alternative trick which I have used in my code and found much less > disturbing is to prepend an arbitrary, hopefully non-existent, file name > so the list of arguments will never be empty even if the variable is. > > rm -f NOTFOUND $(VAR) i

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

On 15 Dec 2021 14:48, Karl Berry wrote: > > rm -f NOTFOUND $(VAR) > i think this is an interesting route. > > I agree. > > we could do: > rm -f $(am__rm_f_notfound) ... > and am__rm_f_notfound could be set based on the configure test. > > Sounds plausible to me.

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

On 11 Dec 2021 09:33, Peter Johansson wrote: > On 10/12/21 15:47, Mike Frysinger wrote: > > if it's dropped, i'm not sure how users are supposed to fix things. > > the error message says to install GNU coreutils, but if GNU coreutils > > uses automake and presents the sam

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

On 03 Jan 2013 20:14, Stefano Lattarini wrote: > Reference: > > > [This is posted also to the automake list to ensure a wider audience. > Discussion should continue exclusively on the bug-automake list] > > OK, time to resurrect this thread.

bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?

confirm 31728 severity 31728 wishlist On 05 Jun 2018 15:09, Nick Bowler wrote: > The trouble is that dmalloc appears to be non-free: the license does > not seem to permit distribution for a fee (see below). first this part. ianal, so i won't try to interpret the nuance here, but it seems a bit

bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems

This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems to be a kerberos tool installed as "kcc" which breaks the check. Also resync with latest autoconf which searches for clang++ too. * configure.ac: Skip KCC check on case-insensitive filesystems. Add clang++ to the C++ search

bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4

On 03 May 2018 10:11, Jamal Natour wrote: > As a user of C++11 and C++14, I use the ax_cxx_compile_stdcxx variants, > these have seemed to work on the various combinations of > platforms/compilers I've used. > > https://github.com/jamal-fuma/fuma_m4/blob/master/ax_cxx_compile_stdcxx.m4 >

bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?

On 11 Dec 2021 15:42, Karl Berry wrote: > i tend to agree with this sentiment that the macro doesn't really fit > with automake's mission. and more importantly, i think the ecosystem > has grown significantly since the macro was first added back in 1996. > > I also agree, but I still

bug#18714: duping to newer bug

forcemerge 20314 18714 18715 looks like this was reported later again, and then resolved & fixed there. it was released in automake-1.16. http://git.savannah.gnu.org/cgit/automake.git/commit/?h=7c25c996d1c7c212a5981aa0e9c4434b6f33f7b8

bug#18714: closing

i can't figure out why debbugs isn't merging the reports, so just close this one

bug#18714: duping to newer bug

forcemerge 20314 18714 18715 stop

bug#54363: [PATCH] doc: refer to automake manual in all man pages

Fixes automake bug https://bugs.gnu.org/54363. There is no "aclocal" manual as it's all integrated into the automake manual, so have all the help2man calls force automake as the manual. * doc/local.mk: Use --info-page=automake for man pages. --- doc/local.mk | 2 +- 1 file changed, 1

bug#54363: aclocal info page is not installed

On 13 Mar 2022 00:45, Esteve Varela Colominas wrote: > Running "man aclocal" mentions the availability of a full texinfo manual for > the tool at the bottom. However, running "info aclocal" brings up the same > man page. I'd like to have this texinfo page shipped alongside the texinfo > page

bug#7610: [PATCH v2 committed] automake: support embedded \# in variable appends

Fixes automake bug https://bugs.gnu.org/7610. Use of \# is not portable. POSIX does not provide any way of retaining the # marker in variables. There is wide spread support for \# though in GNU & BSD Make implementations. Today, with plain variable assignments, Automake leaves the line alone:

bug#32800: [PATCH/committed] tests: make silent-custom regex a little more robust

Fixes automake bug https://bugs.gnu.org/32800. Have the regex match the entire path with word boundaries on both sides. This should reduce false positives when the full cwd happens to match parent directories. * t/silent-custom.sh: Update the header output regex. --- t/silent-custom.sh | 2 +-

bug#33819: automake-1.16.1 test failures on NetBSD

On 21 Dec 2018 10:46, Thomas Klausner wrote: > When running the self tests on NetBSD (8.99.27/amd64) with perl > 5.28.1, I see 26 test failures. > > The log is attached. from the log: > FAIL: t/instspc this seems to be due to install-sh being used over normal mkdir -p. but that should be fine

bug#54063: automake cannot run without generated Texinfo manual

On 19 Feb 2022 15:03, Patrice Dumas wrote: > In Texinfo, we have a texinfo manual which is automatically generated > from Pod sections from Texinfo perl modules. When this generated manual > is removed, automake cannot run anymore. To workaround this issue, we > have a generation of a fake

bug#34151: GNU Automake 1.16.1 FAIL: 4 on Solaris 10 SPARC

On 20 Jan 2019 22:00, Dennis Clarke wrote: > The usual. Nothing new here. Four failed tests on ye old Solaris 10 > sparc with Oracle Studio 12.6 compiler tools. > > test-suite.log attached. from the log: > FAIL: t/dist-formats > + bzip2 -d parallel-compression-1.0.tar.bz2 > bzip2: Caught a

bug#33819: automake-1.16.1 test failures on NetBSD

On 24 Feb 2022 11:23, Thomas Klausner wrote: > FAIL: t/distcheck-override-infodir > FAIL: t/instdir-texi > FAIL: t/silent-texi > FAIL: t/txinfo-builddir > FAIL: t/txinfo-clean > FAIL: t/txinfo-info-in-srcdir > FAIL: t/txinfo-include > FAIL: t/txinfo-many-output-formats > FAIL:

bug#54063: [PATCH] automake: fall back gracefully when texinfo inputs don't exist

Fixes automake bug https://bugs.gnu.org/54063. The function scanning for @setfilename will fall back to a default value if the input doesn't have one defined. But we need to handle the case where the file doesn't even exist before falling back. * bin/automake.in: Scan /dev/null for @setfilename

bug#54063: automake cannot run without generated Texinfo manual

On 24 Feb 2022 11:19, Patrice Dumas wrote: > On Thu, Feb 24, 2022 at 01:52:21AM -0500, Mike Frysinger wrote: > > On 19 Feb 2022 15:03, Patrice Dumas wrote: > > > In Texinfo, we have a texinfo manual which is automatically generated > > > from Pod sections from

bug#20713: [PATCH] m4: handle id failures when checking ustar support

Fixes automake bug https://bugs.gnu.org/20713. If `id` fails, display a specific warning message to the user. * m4/tar.m4: Check $am_uid & $am_gid if they're unknown. --- m4/tar.m4 | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/m4/tar.m4 b/m4/tar.m4 index

bug#53780: Automake failing with conditional AC_CONFIG_FILES

On 04 Feb 2022 17:12, Valio Valtokari wrote: > I have a project that supports multiple platforms (windows and linux as of > right now). To implement testing functionality I use a library that I > haven't configured for windows in my project yet. As such, my configure.ac > has these lines: > >

bug#14959: automake 1.14 failure on OS X 10.6.8: fort5

On Fri, 26 Jul 2013 11:32:18 -0400, Diab Jerius wrote: > The fort5 test fails on Mac OS X 10.6.8. the failing part of the log: /bin/sh ./libtool --tag=FC --mode=link gfortran -g -O2 -o libhello.la -rpath /usr/local/lib foo.lo bar.lo libgoodbye.la libtool: link: gfortran -dynamiclib

bug#19311: [FYI] {minor} Expose automake bug#19311

On 17 Dec 2014 17:13, Stefano Lattarini wrote: > AC_PROG_CC called before AC_CONFIG_AUX_DIR can silently force wrong > $ac_aux_dir definition. looks like this was merged to fix this bug but forgot to close the report -mike

bug#7610: [PATCH] automake: support embedded \# in variable appends

Fixes automake bug https://bugs.gnu.org/7610. Use of \# is not portable. POSIX does not provide any way of retaining the # marker in variables. There is wide spread support for \# though in GNU & BSD Make implementations. Today, with plain variable assignments, Automake leaves the line alone:

bug#54063: automake cannot run without generated Texinfo manual

On 25 Feb 2022 16:06, Karl Berry wrote: > Adding a note to the manual is fine, but what would be (much) more > likely to actually get noticed by users is a runtime warning. What is > the actual behavior when the basename and @setfilename don't match? i don't think it's possible to detect from

bug#32868: [PATCH v2] m4: rework silent-rules macros to avoid double expansion

On 28 Feb 2022 15:58, Karl Berry wrote: > Fixes automake bug https://bugs.gnu.org/32868. > > Looks fine to me. > > +./configure -C > +grep '^AM_DEFAULT_VERBOSITY = 1' Makefile > > Good :). > > I remain steadfastly opposed to (ever) changing the default to be silent > rules, as

bug#10828: [PATCH] rm: handle -f w/no arguments gracefully

Fixes automake bug https://bugs.gnu.org/10828. Delete the configure check that would abort if `rm -f` does not work, and delete the plans to make this a hard requirement in the future. Instead, test to see if `rm -f` fails w/out arguments. If it does, define am__rm_f such that it always passes

bug#17614: parallel compilation fails

On 21 Feb 2022 12:15, Peter Johansson wrote: > On 25/1/22 16:24, Mike Frysinger wrote: > > On 19 Jan 2022 18:32, Peter Johansson wrote: > >> On 19/1/22 18:10, Mike Frysinger wrote: > >>> assuming it still fails with Automake 1.16 ... > >> > >> I'll

bug#20713: aclocal/tar.m4 and solaris 5.10

On 21 Feb 2022 16:26, Karl Berry wrote: > should we change "unknown" to $GID & $UID respectively ? > > I guess it couldn't hurt, although I doubt it makes any difference in > practice. i feel like you just accidentally wrote Automake's motto :p > if test $am_uid = "unknown"; then > >

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

On 17 Feb 2022 16:33, Karl Berry wrote: > Hi Damian - thanks for the report. > > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ > $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \ > $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ >

bug#20713: aclocal/tar.m4 and solaris 5.10

On 22 Feb 2022 16:29, Karl Berry wrote: > The "test" item, most of the way down in the "Limitations of Shell > Builtins" node of the Autoconf manual, reports a lot of the things that > have led to the common forms/workarounds. >

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

On 23 Feb 2022 01:12, Mike Frysinger wrote: > my inclination is to introduce two new variables that would be used for > libtool > & non-libtool, and only when compiling. > * xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override > the compiler on

bug#19579: Long lines, short awk

On 14 Feb 2022 01:14, Daniel Richard G. wrote: > On Mon, 2022 Feb 7 23:03-05:00, Mike Frysinger wrote: > > can you provide an example that reproduces the issue ? or link to the > > package you're working on (assuming it's OSS) ? i checked my own > > projects and it didn't

bug#19418: AC_CONFIG_FILES / stamp-h? problem

On 22 Feb 2022 12:53, Jeff Squyres (jsquyres) wrote: > I'm afraid I can't easily tell. > > It looks like I added a workaround in > https://github.com/open-mpi/ompi/commit/40dd4c5b766ff62a681692b1fa6b72a1023fc81f > on Dec 20, 2014 (the same day that I initially filed this bug report). > > Half

bug#32868: [PATCH v2] m4: rework silent-rules macros to avoid double expansion

Fixes automake bug https://bugs.gnu.org/32868. The AM_SILENT_RULES macro defines all the silent-rules related setup. It's also called by users to change the default verbosity level. This leads to a quirk where automake calls it, expands the full context, and then users call it, and it's fully

bug#32868: Check if make supports nested variables is done twice when using silent rules

On 28 Sep 2018 20:47, Jacob Kroon wrote: > If I use AM_SILENT_RULES([yes]) in my configure.ac, when I run the > configure scripts I see this: > ... > checking whether make supports nested variables... yes > checking whether make supports nested variables... (cached) yes > ... > > If I remove

bug#20031: [PATCH] tests: fix yacc C++ tests with some C++ compilers

Fixes automake bug https://bugs.gnu.org/20031. The C++ standard does not require symbols be placed into the global namespace, just in the std namespace. The GNU implementation will place symbols in both. For our specific code, we don't care either. Unfortunately, it looks like generated flex

bug#8362: make install prefix inserted in source code with generated python files

On Mon, 28 Mar 2011 09:36:45 +0200, A.T.Hofkamp wrote: > As far as I know, "make install prefix=/path/to/writable/dir" should only > change the place where > files are copied to, instead of injecting that new prefix into the source > code. However, for Python > source files that are

bug#20077: automake / silent-rules / $(V)

On Fri, 27 Mar 2015 17:45:30 +0100, Pavel Raiskup wrote: > On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote: > > I just stumbled across an issue where a project fails to compile using > > automake and silent-rules with $V being set to sth. else other than '1' > > or '0'. > > > > This is

bug#19961: [PATCH 1/2] automake: support check-hook target

Related to automake bug https://bugs.gnu.org/19961. Add hook support for the check target as requested by Shahbaz Youssefi. * NEWS: Mention new check-hook. * bin/automake.in: Run check-hook if defined. * doc/automake.texi: Document new check-hook. --- NEWS | 2 ++ bin/automake.in

bug#19961: [PATCH 2/2] automake: allow check-local to run early

Fixes automake bug https://bugs.gnu.org/19961. * NEWS: Note that check-local may run earlier that before. * bin/automake.in: Allow check-local to run before check-am instead of after like check-hook does. --- NEWS| 5 + bin/automake.in | 7 +-- 2 files changed, 10

bug#19961: check-local is kind of like check-hook

On 02 Mar 2015 13:17, Shahbaz Youssefi wrote: > On Mon, Mar 2, 2015 at 12:18 AM, Peter Johansson wrote: > > On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote: > >> > >> To align this with the other -local rules, why not generate it like this? > >> > >> check-am: all-am check-local > >> $(MAKE)

bug#54080: bug#19961: check-local is kind of like check-hook

On Mon, 02 Mar 2015 13:17:12 +0100, Shahbaz Youssefi wrote: > I do have a related suggestion nevertheless. You see, no matter how > many scenarios you think about, there is always some use-case that's > going to be desired by someone but is unforeseen. Why not just create > a general rule? My

bug#19418: AC_CONFIG_FILES / stamp-h? problem

On Sat, 20 Dec 2014 15:48:49 +, Jeff Squyres (jsquyres) wrote: > I have found what appears to be a subtle bug in the Autotools, and I *think* > it may be in Automake. ...but I am not sure; it could also be a bug in our > m4 code. it's been ... a while. have you managed to track this down

bug#20300: [PATCH] automake: allow required files to be in subdirs

Fixes automake bug https://bugs.gnu.org/20300. The internal method for caching path lookups expects the $filename to only be a filename. If it's actually a subdir/file itself, then the cache logic gets confused, and it never matches. This manifests as AC_REQUIRE_AUX_FILE([subdir/file]) claiming

bug#20713: aclocal/tar.m4 and solaris 5.10

On Mon, 01 Jun 2015 21:02:32 +, Karl Berry wrote: > Running a configure script on solaris 5.10 generated with automake-1.15, > I got these errors about id, which being pre-POSIX, does not support -u: > > id: illegal option -- u > Usage: id [-ap] [user] > id: illegal option --

bug#32868: Check if make supports nested variables is done twice when using silent rules

On 20 Feb 2022 16:27, Zack Weinberg wrote: > > i'm inclined to bring this back as the way to opt-in to silent-rules > > by default. > > And I’m still absolutely opposed to making it even *possible* to have silent > rules be on by default. In fact I’d like to see —enable-silent-rules removed, >

bug#32868: [PATCH] m4: rework silent-rules macros to avoid double expansion

Fixes automake bug https://bugs.gnu.org/32868. The AM_SILENT_RULES macro defines all the silent-rules related setup. It's also called by users to change the default verbosity level. This leads to a quirk where automake calls it, expands the full context, and then users call it, and it's fully

bug#7610: [PATCH] automake: support embedded \# in variable appends

On 20 Feb 2022 15:25, Karl Berry wrote: > Use of \# is not portable. > > Is there any known make implementation which does not preserve the #? > > foo = blah\#blah > foo += what > -> warning: escaping \# comment markers is not portable > -> foo = blah\#blah what > >

bug#32868: [PATCH] m4: rework silent-rules macros to avoid double expansion

On 20 Feb 2022 19:14, Mike Frysinger wrote: > --- a/m4/silent.m4 > +++ b/m4/silent.m4 > @@ -5,12 +5,12 @@ > # gives unlimited permission to copy and/or distribute it, > # with or without modifications, as long as this notice is preserved. > > -# AM_

bug#53340: [PATCH] python: use xargs -n when uninstalling files

Fixes automake bug https://bugs.gnu.org/53340. If the system has xargs, then utilize it to uninstall files to stay within long command line limits. If the system doesn't have xargs, fall back to running the remove command one at a time. Since every reasonable system should have `xargs -n`, and

bug#20831: [PATCH/committed] NEWS: fix typo in fix-timestamp.sh script name

As pointed out by Eric Blake. * NEWS: Fix typo. --- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 74ad6d612560..c5ccd9387c0a 100644 --- a/NEWS +++ b/NEWS @@ -821,7 +821,7 @@ New in 1.13: - The missing script has thus become useless as a (poor) way

bug#20831: Can m4 be built without automake?

retitle 20831 `missing` script handling of broken timestamps tag 20831 = confirmed thankyou

bug#34924: Default _SOURCES fails when the target contains dots

On 20 Mar 2019 15:21, Дилян Палаузов wrote: > I expect that the line > > a_b_d_e_f_g_SOURCES = a/b/d-e-f.g.c > > to be superflous, as this is a “Default _SOURCE”, but `make` fails with > > make[1]: *** No rule to make target 'a/b/d-e-f.c', needed by > 'a/b/d_e_f_g-d-e-f.o'. Stop > > g is

bug#53782: supporting objects with & w/out libtool via conditionals

see the attached example configure.ac & Makefile.am. it fails: $ autoreconf -vfi ... Makefile.am: error: object 'source.$(OBJEXT)' created both with libtool and without if the Makefile.am line is enabled though: lib_a_CFLAGS = $(AM_CFLAGS) it works. seems like we should be able to handle this

bug#23599: Including search directories for pdf and dvi

i believe this will be fixed in the next release with the patches i just merged. please feel free to reopen if that doesn't work out. -mike signature.asc Description: PGP signature

bug#53530: [PATCH] python: add 3.10 - 3.15 to the version search list

On 26 Jan 2022 06:37, Mike Frysinger wrote: > Fixes automake bug https://bugs.gnu.org/53530. > > Based on the cadence of Automake releases, add the current Python > release (3.10), the current Python development (3.11), and then 4 > more versions on top of that. It doesn'

bug#23599: [PATCH 1/2] texi: pass automatic -I to dvi & pdf generation

On 26 Jan 2022 19:50, Karl Berry wrote: > +## if it is in srcdir (-I $(srcdir) is set in %MAKEINFOFLAGS%), and in > case > +## texi2dvi automatically fallsback to using makeinfo for expanding (-E). > +## If texi2dvi doesn't fallback, we also pass %MAKEINFOFLAGS% directly > below. >

bug#23599: [PATCH 2/2] texi: define new AM_TEXI2FLAGS variable

On 26 Jan 2022 19:50, Karl Berry wrote: > I don't really understand why this patch is in two parts, with seemingly > the same change, but whatever, doesn't matter. they're logically independent things. one fixes a bug by adding -I paths, the other is a nice-to-have new feature. > *

bug#23599: [PATCH 1/2 v2] texi: pass automatic -I to dvi & pdf generation

Fixes automake bug https://bugs.gnu.org/23599. When generating info/html pages, automake adds -I flags to source dirs that contain the texi files, but it doesn't do this for dvi or pdf formats. Instead, automake has been relying on texi2dvi to use makeinfo for expanding macros, and it hasn't

bug#23599: [PATCH 2/2 v2] texi: define new AM_TEXI2FLAGS variable

To provide a bit more flexibility when invoking TEXI2DVI & TEXI2PDF, and provide a bit of symmetry with .info & .html generation, provide a AM_TEXI2FLAGS setting that is passed to all TEXI2xxx invocations. * doc/automake.texi: Mention new AM_TEXI2FLAGS setting. * lib/am/texibuild.am: Pass

bug#38043: [PATCH 1/6] py-compile: clean up usage info

Include the full summary of options in the output. * lib/py-compile: Update usage output. * t/py-compile-usage.sh: Update test to match new output. --- lib/py-compile| 8 +++- t/py-compile-usage.sh | 4 ++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git

bug#38043: [PATCH 2/6] py-compile: handle filenames with whitespace

The list of files is put into a string and then split on whitespace. Fix the way the list of files are passed to the compile script. * lib/py-compile: Pass files as arguments, not as a string. * t/py-compile-files.sh: New test. --- lib/py-compile| 14 +- t/py-compile-files.sh

bug#38043: [PATCH 4/6] py-compile: drop support for Python 0.x & 1.x

Python 2.0 was released in 2000. There's really no way for us to check those old versions, so let's just drop them. No one will miss them. * lib/py-compile: Abort if major version 0 or 1 is found. * t/py-compile-env.sh: Rework slightly to handle new version probing. --- lib/py-compile |

bug#38043: [PATCH 3/6] manual: document Python version support status

Clarify to users what versions of Python are supported and until when. This will make it easier for us to decide what versions to support. * doc/automake.texi: Add Supported Python versions section. --- doc/automake.texi | 53 +++ 1 file changed, 53

bug#38043: [PATCH 6/6] py-compile: fix optimized compiling for Python 3.5+

dalg...@ix.netcom.com Mike Frysinger vap...@gentoo.org diff --git a/lib/py-compile b/lib/py-compile index f72d4945da96..d34bb2dd2364 100755 --- a/lib/py-compile +++ b/lib/py-compile @@ -131,6 +131,13 @@ case $python_major in ;; esac +python_minor=`$PYTHON -c

bug#38043: [PATCH 5/6] py-compile: fix display when compiling multiple files

The compilation steps print the filename as it runs, but forgets to add a space after it, so they all get squashed together: $ ./py-compile 1.py 2.py 3.py Byte-compiling python modules... 1.py2.py.3.py * lib/py-compile: Add missing write. --- lib/py-compile | 4 ++-- 1 file changed, 2

bug#19579: Long lines, short awk

On Tue, 13 Jan 2015 01:01:44 -0500, Daniel Richard G. wrote: > I am building a source package, prepared with Automake 1.15, on HP-UX. > While running the configure script, I get > > [...] > config.status: creating include/Makefile > config.status: creating scripts/Makefile >

bug#30127: [PATCH] ar-lib: ignore -nologo option

We already invoke $AR with -NOLOGO all the time, so we can ignore the option entirely if the user specifies it. * lib/ar-lib: Ignore -NOLOGO. --- lib/ar-lib | 4 1 file changed, 4 insertions(+) diff --git a/lib/ar-lib b/lib/ar-lib index 9dc8ef6df054..54c6bdbf7f1b 100755 --- a/lib/ar-lib

bug#34846: top_builddir incorrectly formulated when src directory at same level as configure

On 13 Mar 2019 20:23, Hans-Bernhard Bröker wrote: > Am 13.03.2019 um 16:44 schrieb Allwright, James: > > I believe I have found a bug in automake relating to the parsing of > > filepaths and/or directories. > > I believe you have used automake incorrectly. > > > In proj3/ Makefile.am I have >

bug#30172: [PATCH] tests: do not assume AM_MAKEINFOHTMLFLAGS is used in non-html targets

From: Mathieu Lirzin Fixes automake bug https://bugs.gnu.org/30172. Since AM_MAKEINFOHTMLFLAGS overrides AM_MAKEINFOFLAGS only for html targets, make sure we restore the hacked up makefile before testing the non-html formats. This normally doesn't cause a problem for most people, but if their

bug#30172: dvi, ps, and pdf targets use AM_MAKEINFOFLAGS

On 19 Jan 2018 16:30, Mathieu Lirzin wrote: > The test suite fails for “t/txinfo-many-output-formats.sh” and > “t/txinfo-many-output-formats-vpath.sh”. > > $ make check \ > TESTS="t/txinfo-many-output-formats.sh > t/txinfo-many-output-formats-vpath.sh" > > TEXINPUTS=".:$TEXINPUTS" \ >

  1   2   >