bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

On 2024-04-17 11:55, Karl Berry wrote: > so whether it is > @NATIVE_FALSE@install-exec-local: > @NATIVE_FALSE@uninstall-local: > or > @NATIVE_FALSE@uninstall-local: > @NATIVE_FALSE@install-exec-local: > depends on some hash table traversal or what. > > Thanks for the

bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

bug#64743: Speed up GNU make's internal processing

On 20/07/2023, Bruno Haible wrote: > Karl Berry wrote: >> I just hope those weird-looking %:: rules do not cause trouble with >> other makes. I guess we'll find out. > > I tested the default 'make' of various OSes, before submitting the patch. > Whether some other, rarely-used 'make'

bug#19614: Split packaging invocation to catch errors

On 2023-07-17, Karl Berry wrote: > Hi Dimitrios, Bogdan - back on this bug from 2015 (sorry): > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19614 > > Bogdan sent a patch that splits the tar and compress into separate > invocations. It seems basically good to me, but the dist-formats test >

bug#61278: Automake warns about LDFLAGS for defined library

On 2023-02-04, Reuben Thomas via Bug reports for Automake wrote: > When automake is run, it warns: > > liba2ps/Makefile.am:63: warning: variable 'libnowarnings_a_LDFLAGS' is > defined but no program or > liba2ps/Makefile.am:63: library has 'libnowarnings_a' as canonical name > (possible typo) > >

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

On 14/01/2023, Mike Frysinger wrote: [...] >> I tried several other implementations and they follow the POSIX >> behaviour by default, adding -e only when errors are not suppressed. > > this is exactly my point. if i'm developing a project with automake > and i'm using gnu make, i can easily

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

On 2023-01-13, Mike Frysinger wrote: > On 13 Jan 2023 16:01, Karl Berry wrote: >> I am doubtful about blithely defining .POSIX unconditionally. I feel >> sure that will break existing Makefiles. I don't think we should do that. >> >> Detecting .POSIX in an existing Makefile.am and moving it to

bug#60607: Making dvi target do nothing

On 2023-01-06, Reuben Thomas via Bug reports for Automake wrote: > I'm using automake 1.16.5. The advice about how to disable the "dvi" > target doesn't seem to work. > > In the manual it says: > >To make ‘dvi’ into a do-nothing target, see the example for > ‘EMPTY_AUTOMAKE_TARGETS’ in *note

bug#53780: Automake failing with conditional AC_CONFIG_FILES

On 2022-02-20, Mike Frysinger wrote: > can you link to the project/source ? the snippet you posted isn't > complete, and adding a few more lines doesn't cause automake crash for me. Here is a minimal reproducer: % cat >configure.ac <<'EOF' AC_INIT([test], [0]) AM_INIT_AUTOMAKE([foreign])

bug#53780: Automake failing with conditional AC_CONFIG_FILES

On 2022-02-04, Valio Valtokari wrote: > Hello, > > 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#49901: Bug in build c-ares [too many loops]

On 17/08/2021, Brad House via Bug reports for Automake wrote: > This ended up being the fix to needing to run autoreconf -fi multiple > times: > https://github.com/c-ares/c-ares/commit/e73fb47 Probably an OK workaround. I suspect the effect of this change is to get aclocal to pull in the

bug#49901: Bug in build c-ares [too many loops]

On 17/08/2021, Brad House via Bug reports for Automake wrote: > On 8/17/21 1:06 PM, Nick Bowler wrote: >> On 2021-08-17, Brad House via Bug reports for Automake >> wrote: >>> I'm one of the maintainers of the c-ares project at >>> https://github.com/c-ares/c-ar

bug#49901: Bug in build c-ares [too many loops]

On 2021-08-17, Brad House via Bug reports for Automake wrote: > I'm one of the maintainers of the c-ares project at > https://github.com/c-ares/c-ares and have had a couple of users report > this issue. I took a quick glance and I found this:

bug#50046: Probably a bug

On 2021-08-15, Karl Berry wrote: > two expansions of AM_INIT_AUTOMAKE in your configure.ac. > ... > diagnostic message was certainly not very useful! > > Fully agreed. > > Nick, any chance you could easily write a patch to generate a decent > error message for this? I am tied up with

bug#50046: Probably a bug

On 2021-08-14, José Hipólito Moyano wrote: > I attached the project files in the email. Maybe they were filtered :-) > Here they go again (maybe the C code won't compile XD, I was just > starting) [...] >> automake: error: global options already processed Your error is presumably caused by

bug#45756: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver

On 2021-01-09, R. Diez wrote: > [Resending in hopes it will attach to the new bug. --karl] > >> [...] >> At any rate, it would be extremely helpful to have a minimal-as-possible >> runnable (automake-able) example showing the case where the + needs to >> be prepended. rdiez, can you create such a

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

On 18/04/2020, Vincent Lefevre wrote: > On 2020-04-18 15:04:08 -0600, Karl Berry wrote: [...] >> Also, not that I wrote any of this, but it seems to me that the >> pervasive assumption is that the automake user in fact owns the file >> trees in question. Thus rm -rf should work even if it's mode

bug#35848: Should automake use gmake by default if exists?

Hello, On 5/22/19, libor.buk...@oracle.com wrote: > On 5/21/19 5:37 PM, Nick Bowler wrote: >> On 5/21/19, libor.buk...@oracle.com wrote: >>> automake expects GNU make to support dependency tracking. >>> >>> On Solaris it works well if MAKE variable is set t

bug#35848: Should automake use gmake by default if exists?

On 5/21/19, libor.buk...@oracle.com wrote: > automake expects GNU make to support dependency tracking. > > On Solaris it works well if MAKE variable is set to gmake during the > configuration, otherwise, it fails with the following error. > > config.status: error: Something went wrong

bug#35762: (No Subject)

On 2019-05-16, howaboutsyne...@protonmail.com wrote: > On Thursday, May 16, 2019 8:12 PM, Eric Blake wrote: [...] >> : >"$log_file" > Very cool! Thank you very much! I'll use that in my local automake > rebuild. Where can I find more information about ":" ? it seems kinda > tough to search for.

bug#35526: misleading documentation about flag variable ordering

On 5/1/19, Daniel Kahn Gillmor wrote: > https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering > says: > > The reason ‘$(CPPFLAGS)’ appears after ‘$(AM_CPPFLAGS)’ or > ‘$(mumble_CPPFLAGS)’ in the compile command is that users should > always have the last

bug#33594: TEXINFO_TEX file is not in dist

Hi Ben, On 2018-12-02, Ben Elliston wrote: > When setting TEXINFO_TEX to a different location (eg, > doc/texinfo.tex), the file is no longer distributed in the dist > tarball. Shouldn't it be? This actually is the documented behaviour[1]: ... if you set the TEXINFO_TEX variable (see below),

bug#33166: automake --add-missing does not install config.rpath when AM_ICONV is used

On 10/26/18, Hans-Bernhard Bröker wrote: > Am 26.10.2018 um 17:06 schrieb Stuart Caie: >> Technically, AM_ICONV is not distributed with automake, and neither is >> is config.rpath. However, automake recognises config.rpath as a special >> file to distribute nonetheless. > > That's not really

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

Hello, On 10/18/18, Julien COURTAT wrote: > Here's my bug report, I'm building my software out of the source tree, this > is called parallel build (very nice feature). > The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DANY > and VPATH=@MYDIR@ and the corresponding Makefile

bug#32269: Expanding variables

On 7/25/18, Philip Prindeville wrote: > Since automake/autoconf are responsible for generating Makefiles, we > could add something like: > > val.%: > @$(if $(filter undefined,$(origin $*)),\ > echo "$* undefined" >&2, \ > echo '$(subst ','"'"',$($*))' \ > )

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

Hi, I have some doubts about the automake-provided macro AM_WITH_DMALLOC. This appears to be a development tool which could be useful to help programmers debug their packages. It has a very brief description in the Automake manual in section 6.4.1 "Public Macros"[1], including a link to the

bug#28838: Authoritative answer about licensing and copyright of provided scripts and templates

On 2017-10-14, Joël Krähemann wrote: > I need some authoritative answer about copyright notices to be used > for scripts and templates. The files generated by autoscan, autoconf, > automake or alike. > > I need this information in order to proceed with a submission on >

bug#27781: LIBOBJS should depend on LIBOBJDIR

On 8/23/17, Mathieu Lirzin wrote: > Michael Haubenwallner writes: >> Another thought about the final "$(LIBOBJS): .../.dirstamp" Makefile >> line: If I remember correctly, there have been (non-GNU) make >> implementations thatchoke on this

bug#27188: lex/yacc with subdir-objects and --disable-dependency-tracking broken

On 6/4/17, Mathieu Lirzin wrote: > Nick Brown writes: >> diff --git a/lib/am/lex.am b/lib/am/lex.am >> index d7ddc77..6357507 100644 >> --- a/lib/am/lex.am >> +++ b/lib/am/lex.am >> @@ -23,6 +23,7 @@ endif %?MAINTAINER-MODE% >> >> ?GENERIC?%EXT%%DERIVED-EXT%:

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

On 2016-02-29, Vincent Lefevre wrote: > When I cross-compile for Windows and run "make check" without > LOG_COMPILER=wine (by mistake), strange files appear. [...] > ./tadd.exe: 1: ./tadd.exe: MZ ��¸@€º´: not found > ./tadd.exe: 2: ./tadd.exe: : not found > ./tadd.exe: 1:

bug#22331: nodist_nobase_ variable does not treat nobase_ as a special prefix

On 1/8/16, Simon McVittie wrote: > I'm using Automake 1.15 (Debian's automake package version 1:1.15-3) and > Autoconf 2.69 (autoconf 2.69-9). > > If I generate a header file at runtime, and I want it installed in a > subdirectory, it makes sense to use both the

bug#20715: tap-driver.sh 'missing test plan' message contradicts the TAP Standard

On 2015-06-02 11:08 -0700, Arthur Schwarz wrote: [Nick Bowler wrote] On 2015-06-02 09:40 -0700, Arthur Schwarz wrote: The TAP Standard specifically states that if the test plan is 1..N and the number of test lines are k N, then the k+1 .. N missing test lines are to be considered

bug#20715: tap-driver.sh 'missing test plan' message contradicts the TAP Standard

--- test.sh (Wstat: 0 Tests: 1 Failed: 0) Parse errors: No plan found in TAP output Files=1, Tests=1, 0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU) Result: FAIL The bug is in the TAP documentation. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#20715: tap-driver.sh 'missing test plan' message contradicts the TAP Standard

On 2015-06-02 09:40 -0700, Arthur Schwarz wrote: [Nick Bowler wrote] The plan line has to be mandatory for this feature to work as intended (i.e., for the TAP consumer to determine whether a producer has run to completion or not). An optional plan would be useless. Sorry

bug#20693: SKIP not counted in TAP

the plan line to indicate that the entire test program is to be skipped: 1..0 # skip reason Regards, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#19964: automake fails if files named “install.sh” and “install-sh” are found in the parent directory

. Which unfortunately means changing the automake behaviour could break this usage... However, there is a workaround. If you add AC_CONFIG_AUX_DIR([.]) to configure.ac, then this will cause Automake to not look in .. or ../.., and things should work properly. Cheers, -- Nick Bowler, Elliptic

bug#18929: feature: output test failures to stdout

On 2014-11-02 20:21 +, Ximin Luo wrote: Please have automake automatically dump test logs to stdout for all tests that did not pass. This feature already exists, and is enabled by setting VERBOSE in the environment. For example, VERBOSE=true make check Regards, -- Nick Bowler

bug#16588: TAP driver fails with DOS line endings

don't appear to work anymore. In particular http://testanything.org has been down for maintenance until tomorrow for some time now. [2] https://gnu.org/software/automake/manual/automake.html#Links-and-external-resources-on-TAP Cheers, -- Nick Bowler, Elliptic Technologies (http

bug#14911: automake-1.14 t/ccnoco-lt failure on OS X

considers the above command line as a using both -c and -o, when it clearly does not. So the test will need to be made more robust. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#14177: Incorrect extending of rules in documentation

)$(bindir) \ mv -f $$instprog$(EXEEXT) $$instprog-$(VERSION)$(EXEEXT) \ $(LN_S) $$instprog-$(VERSION)$(EXEEXT) $$instprog$(EXEEXT) [1] https://gnu.org/software/autoconf/manual/autoconf.html#Transforming-Names Hope that helps, -- Nick Bowler, Elliptic Technologies (http

bug#14126: dist_EXTRA_SCRIPTS

or to the manual), since the documentation does say that there is an EXTRA version for each primary (which would include SCRIPTS) in §3.3: https://www.gnu.org/software/automake/manual/automake.html#Uniform Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#13928: VPATH issues with subdir-objects

On 2013-03-11 23:27 +0100, Stefano Lattarini wrote: On 03/11/2013 10:33 PM, Nick Bowler wrote: On 2013-03-11 21:55 +0100, Stefano Lattarini wrote: [...] - from Automake 2.0 onward, only enable the automatic dependency tracking if GNU make is used; we can thus assume the presence

bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2] preproc: add support for relative names in included fragments)

out an otherwise-working feature. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#13435: Please don't kill DJGPP support...

, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

are required. These patches no longer apply to master, but here they are anyway. Nick Bowler (2): Use AC_DEFUN_ONCE to define AM_PROG_CC_C_O. Automatically call AM_PROG_CC_C_O as required. m4/init.m4 | 5 + m4/minuso.m4 | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) -- 1.8.1

bug#13378: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.

If subdir-objects is made the default Automake behaviour, packages will need to add AM_PROG_CC_C_O to their configure.ac. Instead of that, let's just make the functionality provided by AM_PROG_CC_C_O mandatory for C projects, and have Automake automatically call it as required. This change

bug#13378: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.

On 2013-01-13, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 01/13/2013 09:01 PM, Nick Bowler wrote: +dnl Automatically invoke AM_PROG_CC_C_O as necessary. Since AC_PROG_CC is +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be +dnl done later

bug#13349: Re-execute with the correct make implementation

be catastrophic. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#13104: Extending automake rules w.r.t dependencies

to say without looking a concrete example, but the most likely explanation is that the Automake-generated rules are different in the recursive case, such that your custom rules don't actually override anything. Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#12657: Can't have spaces in source files

separated by ‘/’. File name components cannot begin with ‘-’. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#12495: AC_CONFIG_HEADERS with

: $(srcdir)/fooconfig.h.in: $(am__configure_deps) ($(am__cd) $(top_srcdir) $(AUTOHEADER)) rm -f stamp-h2 touch $@ Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#12495: AC_CONFIG_HEADERS with

On 2012-09-27 21:53 +0200, Hib Eris wrote: On Thu, Sep 27, 2012 at 4:20 PM, Nick Bowler nbow...@elliptictech.com wrote: Fortunately in this case, the rule to update fooconfig.h.in also contains a simple touch command, so it does actually update the target timestamp. But it would have been

bug#12142: automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)

will not be performed. Just putting foo: ; in Makefile.am (which says that foo has no prerequisites and can be updated by doing nothing) should fix it right up, without relying on any GNU-make-specific features. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#10878: make dist with read-only srcdir generates read-only tarball

to modify the content of an existing file +in the distribution directory, it should explicitly ensure to make +it readable first: writable I also would drop the words ensure to. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#10878: make dist with read-only srcdir generates read-only tarball

On 2012-02-24 18:37 +0100, Stefano Lattarini wrote: [...] On 02/24/2012 08:09 AM, Nick Bowler wrote: Automake should at least add user write permissions to all files in distdir prior to running dist-hook (and hence prior to generating the distribution tarball). I disagree; in case

bug#10878: make dist with read-only srcdir generates read-only tarball

On 2012-02-24 19:19 +0100, Stefano Lattarini wrote: On 02/24/2012 06:53 PM, Nick Bowler wrote: On 2012-02-24 18:37 +0100, Stefano Lattarini wrote: [...] On 02/24/2012 08:09 AM, Nick Bowler wrote: Automake should at least add user write permissions to all files in distdir prior

bug#10878: make dist with read-only srcdir generates read-only tarball

On 2012-02-24 12:10 -0700, Eric Blake wrote: On 02/24/2012 11:34 AM, Nick Bowler wrote: But it's the package that expects its distributed files to be writable that is assuming too much; if such package wants its expectation to safely hold, it should add something like this in its 'dist-hook

bug#10878: make dist with read-only srcdir generates read-only tarball

this and discovered that there was a source file missing from the distribution that distcheck didn't notice because only maintainer-clean builds failed. Oops!) Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

and more flexible option is to add an option to automake which prints out the location where it finds these files, similar to aclocal --print-ac-dir. Something like (for example) % automake --print-snippet-dir /usr/share/automake-1.11 Cheers, -- Nick Bowler, Elliptic Technologies (http

bug#9587: Automake claims $(*F), $(D), etc. are non-POSIX.

On 2011-10-19 11:05 +0200, Stefano Lattarini wrote: On Friday 23 September 2011, Nick Bowler wrote: Neither bmake nor pmake seem too support $(?F) or $(?D) (both expand to be empty in both inference and target rules). And dmake seems to differ slightly from POSIX wrt the D variants

bug#9579: distcheck does not detect incomplete uninstall as advertised

project, and now distcheck fails when I revert my uninstall-local rule. It's perhaps a bit unfortunate that make infodir='${prefix}/somewhere_else' distcheck no longer works, but I agree that it seems non-trivial to make that work properly. Thanks, -- Nick Bowler, Elliptic Technologies (http

bug#9587: Automake claims $(*F), $(D), etc. are non-POSIX.

-POSIX variable name Makefile.am:2: ?D: non-POSIX variable name Makefile.am:2: D: non-POSIX variable name Makefile.am:2: *D: non-POSIX variable name Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#9587: Automake claims $(*F), $(D), etc. are non-POSIX.

On 2011-09-23 15:02 -0400, Nick Bowler wrote: These variables are supported by (at least) bmake, pmake, dmake and GNU make. I can reproduce this with the following example: I spoke a bit too soon here. Neither bmake nor pmake seem too support $(?F) or $(?D) (both expand to be empty in both

bug#9578: make uninstall fails after make install-data in empty prefix.

([-Wall -Werror foreign]) AC_PROG_CC AC_CONFIG_FILES([Makefile]) AC_OUTPUT EOF % cat foo.c 'EOF' int main(void) { return 0; } EOF % cat bar 'EOF' baz EOF Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

bug#9579: distcheck does not detect incomplete uninstall as advertised

== Based on the quoted paragraph in the manual, I had expected distcheck to fail. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)