bug#38043: Python version language support

On 18 Jan 2022 16:15, Karl Berry wrote: > i'm inclined to drop support for > My recollection is, plenty of people are still using <3.6, EOL or not. > Tempting though it is. dissertation follows. i know it's a lot, and i don't normally like writing this much at a time, but i think this is

Re: multiple online manual versions

On 18 Jan 2022 19:27, Karl Berry wrote: > Having multiple versions of the manual online sounds all to the good to > me. As long as it's being done at all, I wouldn't hesitate to put up > the manuals for every release, not just the major releases. For 1.16.x, > I'm afraid I rather broke the

bug#31728: [PATCH] dmalloc: mark macro as obsolete

On 18 Jan 2022 16:15, Karl Berry wrote: > To me, the question is, does the current AM_WITH_DMALLOC actually work? > Or not? If it does, I see no reason to have it issue a warning, and > thus annoy anyone who has it in their configure.ac, where it is > presumably residing harmlessly. how are you

Re: PATCH: silence Shellcheck warning

On 18 Jan 2022 21:25, Ben Elliston wrote: > On Tue, Jan 18, 2022 at 04:18:52AM -0500, Mike Frysinger wrote: > > that said, automake targets lower than POSIX, so i agree that we > > should leave it be for automake specifically. feel like posting a > > patch to suppress this pa

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

On 18 Jan 2022 11:29, Jim Meyering wrote: > On Tue, Jan 18, 2022 at 10:29 AM Mike Frysinger wrote: > > On 18 Jan 2022 09:48, Jim Meyering wrote: > ... > > > But IMHO that's too much duplication/syntax. > > > How about this instead? > > > > > > c

[PATCH] build: fix race in parallel builds

As reported by Hongxu Jia: > The automake-$(APIVERSION) is a hardlink of automake, if it is > created later than update_mans executing, there is a failure > [snip] > |: && mkdir -p doc && ./pre-inst-env /usr/bin/env perl > ../automake-1.16.1/doc/help2man --output=doc/aclocal-1.16.1 aclocal-1.16 >

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

On 18 Jan 2022 09:48, Jim Meyering wrote: > On Tue, Jan 18, 2022 at 7:46 AM Mike Frysinger wrote: > > From: Thomas Deutschmann > > > > Commit b279a0d46dfeca1ca40057c3c910ab1657d60be5 ("tests: in python > > tests, do not require .pyo files (for python3

Re: PATCH: silence Shellcheck warning

On 22 Jul 2018 14:41, Nick Bowler wrote: > On 7/21/18, Ben Elliston wrote: > > This patch silences a warning from Shellcheck about using old-style > > `...` command substitutions. > [...] > > commit 4d35c7aae97234bf055519075ef03cd4090a1dfc > > Author: Ben Elliston > > Date: Sun Jul 22 08:22:44

Re: [PATCH] doc: Fix a typo

On 08 Apr 2018 16:06, Matthew Leeds wrote: > --- a/doc/automake.texi > +++ b/doc/automake.texi > All of these actions are performed in a temporary directory. Please > note that the exact location and the exact structure of such a directory > (where the read-only sources are placed, how the

Re: [PATCH] lib: drop unused shell variables

lgtm, and still applies cleanly -mike signature.asc Description: PGP signature

Re: [PATCH] Use gender-neutral pronouns in HACKING and t/README

On 08 Apr 2018 16:07, Matthew Leeds wrote: > --- > HACKING | 4 ++-- > t/README | 2 +- thanks for the patch. looks like Jim fixed HACKING: http://git.savannah.gnu.org/cgit/automake.git/commit/?h=7665b8e209888c73ee4dc05256f4f09a703a01e5 but your change to t/README still applies cleanly. -mike

Re: minor docs alteration

On 31 May 2018 22:44, Jefferson Carpenter wrote: > Subject: [PATCH] automake.texi: clarify relationship between configure and > build dir > > I know you what this meant, but as a kid this would have confused me - the > word "in" seems to imply that the "configure" file is inside of the build

multiple online manual versions

currently the automake website only hosts one manual version -- the latest. when working with older code bases, especially when trying to update them to newer versions, it can be helpful to have the older manual available to quickly refer to. can we do this for automake ? i'm thinking of just

bug#38043: Incorrect Python byte-compiling for Python 3 and PyPy3

On 03 Nov 2019 11:45, Michał Górny wrote: > I've noticed that the logic in py-compile is built on assumptions from > Python 2 and does not fit Python 3 well. Notably, there are two or > three bugs here: > > 1. .opt-2 (-OO) level is not compiled for py3.5+. > > 2. .opt-1 (-O) and .opt-2 (-OO)

[PATCH] tests: fix py-compile-basedir.sh: add missing test call

From: Thomas Deutschmann Commit b279a0d46dfeca1ca40057c3c910ab1657d60be5 ("tests: in python tests, do not require .pyo files (for python3)") had a slight logic error in that it missed a `test` call. Reported to Gentoo at https://bugs.gentoo.org/715040. * t/py-compile-basedir.sh: Add test

bug#31728: [PATCH] dmalloc: mark macro as obsolete

This macro doesn't really fit in with Automake's mission. It's a simple configure option to add a specific library when linking. Maybe back in 1996 the dmalloc project was more canonical, but nowadays developers have a wealth of options when it comes to memory debugging, both from ones based in

bug#53338: One test failed in automake 1.14.1

retitle 18564 t/vala-vapi test failure in automake 1.14.1 on Solaris 10 Sparc thankyou for posterity, here's the specific test failure log FAIL: t/vala-vapi = vala-vapi: running pkg-config --version 0.15.0 vala-vapi: running valac --version Vala 0.20.1 vala-vapi: determine

bug#16714: make check failures

retitle 16714 make check failures when ACLOCAL=aclocal is in environment tag 16714 = confirmed thankyou looks like your redundant $ACLOCAL in the environment is breaking things. there should be no reason to have that: ACLOCAL=aclocal -I /usr/share/aclocal that said, we shouldn't be blowing up

[PATCH] gitignore: drop redundant config.h.in~ rule

Since we're ignoring all *~ files, we don't need this explicit one. * .gitignore: Delete config.h.in~ rule. --- .gitignore | 1 - 1 file changed, 1 deletion(-) diff --git a/.gitignore b/.gitignore index 6e7809bffe80..40540ad7ebf0 100644 --- a/.gitignore +++ b/.gitignore @@ -28,7 +28,6 @@

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#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#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#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 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

Re: rm -f # no more args failure?

On 12 Dec 2021 16:17, Karl Berry wrote: > Does anyone here use or know of an active system where plain > rm -f > with no arguments fails? I mean, exits with bad status? > > We are considering changing Automake to assume this works, > although we'd provide for a workaround just in case,

Re: [RFC/PATCH] m4: enable silent build rules by default

On 07 Dec 2021 21:58, Zack Weinberg wrote: > On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > > This has been available since automake 1.11 released over a decade > > ago. Let's flip the default to enable silent builds by default. > > Please don't *e

[PATCH 2/2] m4: enable silent build rules by default

This has been available since automake 1.11 released over a decade ago. Let's flip the default to enable silent builds by default. NB: The "1.20" version is a placeholder. With the warning for devs in 1.17, we can wait a while before rolling this out. --- NEWS | 9 +

[PATCH 1/2] m4: warn when AM_SILENT_RULES default is used

To help ease people into enabling silent rules by default, warn if a package doesn't make an explicit selection. --- NEWS | 10 ++ m4/silent.m4 | 6 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index fb05ee219708..282eb9277a3d 100644 ---

[PATCH] m4: replace AC_DIAGNOSE with m4_warn

AC_DIAGNOSE was marked obsolete with autoconf-2.62 in 2008. * m4/obsolete.m4: Change AC_DIAGNOSE to m4_warn. --- m4/obsolete.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/m4/obsolete.m4 b/m4/obsolete.m4 index 79f3b234bfc5..bf3b68271673 100644 --- a/m4/obsolete.m4 +++

[PATCH] gitignore: update

Ignore all *~ files as editors like to create them, as do some autotool steps. This also matches what autoconf is doing. * .gitignore: Update. --- .gitignore | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 89e71ec97d5a..22f40fe9f51f 100644 ---

Re: [RFC/PATCH] m4: enable silent build rules by default

On 08 Dec 2021 15:02, Karl Berry wrote: > Please don't *ever* make this change. > > I agree with Zack, and just for CI purposes; it is simply too big of an > incompatibility to inflict at this late date. there's nothing incompatible about it. the inputs to the system (how configure & make

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#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#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?

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

[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#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#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#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

[RFC/PATCH] m4: enable silent build rules by default

This has been available since automake 1.11 released over a decade ago. Let's flip the default to enable silent builds by default. --- NEWS | 9 + m4/silent.m4 | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index fb05ee219708..866ace951fd5

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#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#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

Re: [PATCH] dejagnu: add support for silent builds with site.exp

On 27 Nov 2021 18:45, Karl Berry wrote: > Hi Mike, > > Subject: [PATCH] dejagnu: add support for silent builds with site.exp > > I pushed the change. > > https://sourceware.org/git/?p=binutils-gdb.git;a=summary > after you configure+make, you can iterate with just `make site.exp`. >

Re: [PATCH] dejagnu: add support for silent builds with site.exp

On 17 Nov 2021 14:22, Karl Berry wrote: > Thanks for the patch, Mike. > > * lib/am/dejagnu.am (site.exp): Use $(AM_V_GEN) > > Ok. Can you tell me how to discern that this makes a difference? > Is there some test where it can be observed? > I've never actually used dejagnu with Automake. i

[PATCH] dejagnu: add support for silent builds with site.exp

* lib/am/dejagnu.am (site.exp): Use $(AM_V_GEN) and merge all independent shell calls into one. --- lib/am/dejagnu.am | 51 --- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/lib/am/dejagnu.am b/lib/am/dejagnu.am index

[PATCH] config headers: add support for silent builds

* lib/am/remake-hdr.am (%STAMP%): Use $(AM_V_at) and $(AM_V_GEN). (%CONFIG_HIN%): Likewise. --- lib/am/remake-hdr.am | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/am/remake-hdr.am b/lib/am/remake-hdr.am index 0d9f4cd8b9da..c0016cffc626 100644 ---

[PATCH] doc: fix dejagnu variable references

While there is a RUNTESTDEFAULTFLAGS, there is no AM_ variant. The docs probably meant RUNTESTFLAGS which has the variants and is meant to be overridden by people, so swap the name in the docs. * doc/automake.texi (Other Variables): Change RUNTESTDEFAULTFLAGS to RUNTESTFLAGS. ---

Re: Help with static linking

On Sunday 02 June 2013 01:10:36 Kip Warner wrote: On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote: be aware that what ever version of glibc gcc you use to build, the end user cannot have a version older than that or it'll fail to start Do you mean in the case of dynamic linking

Re: Help with static linking

On Saturday 01 June 2013 19:27:46 Kip Warner wrote: On Fri, 2013-05-31 at 08:31 -0500, Robert Boehne wrote: I don't quite understand why you think you need the rest linked statically, Libraries like the following may not be present on the end user's system already: be aware that what

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])

[PATCH] use runtime (not configure time) detection of perl threads

the version/config checking at runtime. Signed-off-by: Mike Frysinger vap...@gentoo.org * bootstrap.sh (PERL_THREADS): Delete assignment and use in sed. * configure.ac (am_cv_prog_PERL_ithreads, PERL_THREADS): Delete all code related to these two variables. * lib/Automake/Config.in (perl_threads

Re: perl ithreads support: why hardcode at configure time ?

On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the generated automake ? I don't know, I wasn't

Re: perl ithreads support: why hardcode at configure time ?

On Friday 11 January 2013 12:21:24 Stefano Lattarini wrote: On 01/11/2013 06:11 PM, Mike Frysinger wrote: On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check

perl ithreads support: why hardcode at configure time ?

i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the generated automake ? it means if you change your perl config or deploy an automake package on a system that has threads disabled, you get errors when trying

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#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#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#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 \

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 \

Re: Fwd: [Bug 347095] installing m4 macros that break random packages

On Tuesday, December 07, 2010 13:56:35 Bruce Korb wrote: Thank you. automake list folks -- the main question is Why are .m4 files being installed and how can I prevent it? because your top level Makefile.am is using: aclocal_DATA = ... when i think you should be using: noinst_DATA = ...

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

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: 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 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 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: 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: 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: `automake -a -c -f` wrongly updates the INSTALL file

On Tuesday 08 January 2008, Ralf Wildenhues wrote: Hello Mike, * Mike Frysinger wrote on Wed, Jan 02, 2008 at 10:44:12PM CET: 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

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: `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: 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: 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]error in Makefile.am

On Thursday 02 November 2006 23:51, Praveen M R wrote: I am getting following message when I enter automake --add-misssing I feel I am doing wrong in Makefile.am. we can only guess at what you're doing wrong unless you actually post the Makefile.am -mike pgp73JtHwWvJP.pgp Description: PGP

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

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

Re: comment handling in aclocal ... bug or feature ?

On Thursday 16 March 2006 19:04, Mike Frysinger wrote: ive attached a patch which updates the comment handling in a few places under the assumption that the behavior i'm seeing is a bug :) seems the deletion of '#.*' is too aggressive ... updated patch removes just dnl comments now ... -mike

Re: comment handling in aclocal ... bug or feature ?

On Thursday 16 March 2006 19:04, Mike Frysinger wrote: ive attached a patch which updates the comment handling in a few places under the assumption that the behavior i'm seeing is a bug :) ok, previous patch was a little too aggressive ... it'd keep '#' comments from being output to the file

comment handling in aclocal ... bug or feature ?

handling in a few places under the assumption that the behavior i'm seeing is a bug :) -mike 2006-03-16 Mike Frysinger [EMAIL PROTECTED] * aclocal.in (scan_configure_dep): Ignore ## lines. (scan_file): Remove dnl and # comments. * tests/commen11.test: New file. * tests/Makefile.am (TESTS): Add

Re: comment handling in aclocal ... bug or feature ?

On Thursday 16 March 2006 23:24, Ralf Wildenhues wrote: Maybe even better if you test the other comment styles as well. attached -mike 2006-03-16 Mike Frysinger [EMAIL PROTECTED] * aclocal.in (scan_configure_dep): Ignore ## lines. (scan_file): Remove dnl and # comments. * tests/commen11

<    1   2   3