bug#74847: change default tar format from v7 to ustar (was: Re: reproducible tar archives)

Back on this suggestion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74847 What do you think about changing Automake's default tar format from v7 to ustar? Given Bruno's experience, ok, let's try. I won't be surprised if problems come out of the woodwork, but maybe it will be fi

bug#74847: change default tar format from v7 to ustar (was: Re: reproducible tar archives)

>> Possibly automake can move from v7 to ustar. Possibly. What's the advantage? --thanks, karl.

bug#74847: change default tar format from v7 to ustar (was: Re: reproducible tar archives)

Hi automake folks, What do you think about changing Automake's default tar format from v7 to ustar? Are you aware of any system 'tar' that does doesn't cope with ustar? What do you think about defaulting to the --format=posix PAX format? It may be just as safe as ustar, and only if a package us

bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

On Tue, Sep 10, 2024 at 10:59 PM Eric Gallager wrote: > > On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote: > > > > Hi Eric - I've just committed a change that I hope fixes the version > > number problem. (See https://bugs.gnu.org/72157) > > > > However, looking at your list of failures, I see t

bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote: > > Hi Eric - I've just committed a change that I hope fixes the version > number problem. (See https://bugs.gnu.org/72157) > > However, looking at your list of failures, I see that some of them are > still about *.dSYM, now relating to distclean.

bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

Hi Eric - I've just committed a change that I hope fixes the version number problem. (See https://bugs.gnu.org/72157) However, looking at your list of failures, I see that some of them are still about *.dSYM, now relating to distclean. E.g., t/yacc-bison-skeleton-cxx.sh shows: ERROR: files lef

bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

Hi Eric - thanks for the follow-up. I believe most or all of those failures are because of a dumb automake version parsing problem that I haven't fixed yet (there's never been a version like 1.16.0.90 before), unrelated to the .dSYM patch. BTW, I ran my make check with -j too. It's pretty unbearab

bug#68179: Re: automake-1.16j on OpenBSD

I pushed Bogdan's patches. Listing several functions to look for in (lib)objc in multiple places doesn't seem ideal, but factoring that out doesn't seem easy either. strip -x: no problem. The general issue: The AC_PROG_OBJCXX macro already tries to compile a trivial program (of course), but the

bug#68179: Re: automake-1.16j on OpenBSD

Bruno Haible , 2024-02-20 12:44: Bogdan wrote: Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found. Does it work if you put AC_LANG([Objective C]) somewhere between the lines cat >> configure.ac << 'END' and the first END following it (i.e., in t

bug#68179: Re: automake-1.16j on OpenBSD

Bogdan wrote: > # Ensure install-strip works when STRIP consists of more than one word. > # This test needs GNU binutils strip. See sister test 'strip3.sh'. > > > And, frankly, I don't know what to do about this. It's the whole > point of the test to use 'strip --verbose' (well, 'strip' + any

bug#68179: Re: automake-1.16j on OpenBSD

Bogdan wrote: > Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found. > Does it work if you put > > AC_LANG([Objective C]) > > somewhere between the lines > > cat >> configure.ac << 'END' > > and the first > > END > > following it (i.e., in the 'configure.a

bug#68179: Re: automake-1.16j on OpenBSD

Bruno Haible , 2024-02-19 01:44: Hello Bogdan, Can you tell us what actually "c++" is on your system? Like e.g. run "c++ --version" or "c++ --help"? $ c++ --version OpenBSD clang version 13.0.0 Target: amd64-unknown-openbsd7.4 Thread model: posix InstalledDir: /usr/bin On my system, A

bug#68179: Re: automake-1.16j on OpenBSD

er --help nor --version? Come to think of it, we're not testing if the files actually got installed, so maybe --help or --version would do after all. If you change the above line to ./configure --prefix="$(pwd)/inst" STRIP='strip --help' does the test pass? (You c

bug#68179: Re: automake-1.16j on OpenBSD

Hello Bogdan, > Can you tell us what actually "c++" is on your system? Like e.g. run > "c++ --version" or "c++ --help"? $ c++ --version OpenBSD clang version 13.0.0 Target: amd64-unknown-openbsd7.4 Thread model: posix InstalledDir: /usr/bin > On my system, Autoconf finds "g++", tests it for

bug#68179: Re: automake-1.16j on OpenBSD

have the STRIPPROG environment variable set. > 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the > test? With the patch, the test succeeds. Note, however, that 'defined __sun' is not an appropriate test for Sun C++ (since g++ also exists on Solaris). For compiler

bug#68179: Re: automake-1.16j on OpenBSD

test? 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the test? Can you tell us what actually "c++" is on your system? Like e.g. run "c++ --version" or "c++ --help"? On my system, Autoconf finds "g++", tests it for an Objective C++ co

bug#68179: Re: automake-1.16j on OpenBSD

test? 3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the test? -- Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS) X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.

bug#33779: Color-coded output from autoconf/automake (was Re: bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES)

On 24 Jan 2023 07:06, Bert Wesarg via Bug reports for Automake wrote: > On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote: > > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake > > wrote: > > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote: > > > No, I don't hav

bug#33779: Color-coded output from autoconf/automake (was Re: bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES)

Full disclosure: the most controversial change in behavior is probably the removal of batch processing files at install time, or maybe also other times, to get for each file a colored silent rule output.. JAVAC is the exception, as all .java files needs to passed at once to the compiler. On Tue, J

bug#33779: Color-coded output from autoconf/automake (was Re: bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES)

On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote: > > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake > wrote: > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote: > > No, I don't have one. It just crossed my eyes while working on more > > silent rules in Autom

bug#33779: Color-coded output from autoconf/automake (was Re: bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES)

On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake wrote: > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote: > No, I don't have one. It just crossed my eyes while working on more > silent rules in Automake. I made Ben recently aware of these changes, > which are avail

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

Your bug report #32868: Check if make supports nested variables is done twice when using silent rules which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 32...@debbugs.gnu

bug#30127: Re[2]: bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

closing this issue out. the original report has been settled, we've merged support for ignoring -nologo, but the -xilib suggestion looks like it needs more work. feel free to post a patch to automake-patc...@gnu.org if you have something you think we can merge. -mike signature.asc Description:

bug#48188: closed (Re: bug#48188: Manual: Multiple outputs)

Your bug report #48188: Manual: Multiple outputs which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 48...@debbugs.gnu.org. -- 48188: http://debbugs.gnu.org/cgi/bugreport

bug#32737: Re: bug#32737: generated LDFLAGS order incorrect

Thank you for your reply and your help, you are correct! This bugreport can be closed. KR, A.Timmermans

bug#30127: Re[2]: bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

I think the –xilib option is invalid when using: $ xilink –xilib … This just gives me an “unrecognized option '/xilib'; ignored” warning, but if I use $ xilink –lib … Then it calls xilib similar to how $ link.exe –lib … calls lib.exe Or in short: $ xilink.exe –lib = xilib.exe $ link.exe –lib = l

bug#30127: Re[2]: bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

sav...@ukr.net writes: > In case you're interested, there is a patch to 'lib/ar-lib', which I use for > libiconv builds using Windows ICC: > === > diff --git a/build-aux/ar-lib b/build-aux/ar-lib > index 463b9ec..3cfddbc 100644 > --- a/b

bug#30128: Re[2]: bug#30128: MSVC: 'invalid numeric argument '/Wl, -DLL, -IMPLIB:.libs...' error for shared GMP builds on Windows

sav...@ukr.net writes: > --- Оригінальне повідомлення --- > Від кого: "Mathieu Lirzin" > Дата: 18 січня 2018, 00:45:20 > > > I have took a quick look a GMP “configure.ac” and it seems that they >> have an option ’--enable-cxx’ which triggers the use of the AC_PROG_CXX >> macro which I guess shou

bug#30127: Re[2]: bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

  --- Оригінальне повідомлення --- Від кого: "Mathieu Lirzin" Дата: 18 січня 2018, 00:57:33 > Indeed, The great news is that support for ‘icl’ has already been added > in Automake 1.15.1 [1]. :-) Thought I checked Automake master before filling report. In any case thank you for a good news

bug#30128: Re[2]: bug#30128: MSVC: 'invalid numeric argument '/Wl, -DLL, -IMPLIB:.libs...' error for shared GMP builds on Windows

  --- Оригінальне повідомлення --- Від кого: "Mathieu Lirzin" Дата: 18 січня 2018, 00:45:20 > I have took a quick look a GMP “configure.ac” and it seems that they > have an option ’--enable-cxx’ which triggers the use of the AC_PROG_CXX > macro which I guess should set things properly (I am n

bug#18301: closed (Re: texi-vers.am: Problem with parallel builds due to vti.tmp)

The patch is here in git: http://git.savannah.gnu.org/cgit/automake.git/commit/?id=74cdef7897da220bf062957ff9699815681441ef

bug#18301: closed (Re: texi-vers.am: Problem with parallel builds due to vti.tmp)

Dear Paul, thank for looking at the problem, looking at the patch and introducing a nice solution! I tried your patch here in my build environment and I do not see any problems. Thank you! Friedrich

bug#14891: [PATCH] automake: account for perl hash order randomization (was: Re: bug#14891: GNU Automake 1.14 FAIL: 5)

> These are not Solaris issues AFAIK, but are due to an incompatible > change in perl 5.18. The patch below should take care of it. > Can you confirm it works? FWIW, it fixed the testsuite problem for me (after change to perl 5.18). I also don't see any problem in your patch. Pavel

bug#14891: [PATCH] automake: account for perl hash order randomization (was: Re: bug#14891: GNU Automake 1.14 FAIL: 5)

On 07/17/2013 01:47 PM, Dennis Clarke wrote: > > FAIL: t/preproc-errmsg.sh > FAIL: t/primary-prefix-invalid-couples.tap 280 - ... > These are not Solaris issues AFAIK, but are due to an incompatible change in perl 5.18. The patch below should take care of it. Can you confirm it works? Thanks,

bug#13520: Some documentation improvements for 'dist' targets & opts (was Re: bug#13520: incomplete type of distribution in "List of Automake options" chapter)

On 01/21/2013 11:11 PM, Roumen Petrov wrote: > Hi automake developers, > > Current (2013-01-21) automake 1.13 manual > http://www.gnu.org/software/automake/manual/automake.html > list quite short distribution types in chapter 17.2 List of > Automake options. > Actually, only 'dist-xz' wasn't menti

bug#13478: [PATCH] docs: serial-tests are not deprecated, just discouraged (was: Re: bug#13478: Don't deprecate or remove 'serial-tests')

On 01/17/2013 07:26 PM, Stefano Lattarini wrote: > On 01/17/2013 07:16 PM, Richard W.M. Jones wrote: >> >> For some reason this is marked as deprecated. >> >> This is bad: parallel tests are fine for tiny tests which use only a >> little bit of memory. However if your tests are very large and use

bug#13378: Cleaning up AC_PROG_CC_C_O semantics (was: Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.)

[+cc bug-autoconf] Reference: On 01/13/2013 10:06 PM, Nick Bowler wrote: > On 2013-01-13, Stefano Lattarini 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 i

bug#13378: [PATCH] subdir-objects: complain if it isn't enabled (was: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one)

Reference: On 01/07/2013 09:08 PM, Stefano Lattarini wrote: > Severity: wishlist > > Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07, > "[ng] subdir-objects: enable unconditionally". > > The fact that Automake-generated M

bug#13378: Backward-compatibility in the autotools (was: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers)

On 01/11/2013 07:19 PM, Eric Blake wrote: > On 01/10/2013 06:33 AM, Stefano Lattarini wrote: >> Reference: >> >> > >> @acindex AC_PROG_CC_C_O >> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in >> -the manner required by

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

elf, rather > than making developers duplicate work? > I think that having an option to say "for every GNUmakefile specified in AC_CONFIG_FILES, generate a corresponding thin-wrapper Makefile" would be a good move. Patches in that direction will be very welcome, once we have agreed

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

[Dropping Automake-NG] On 01/04/2013 01:12 AM, Eric Blake wrote: > On 01/03/2013 04:54 PM, Stefano Lattarini wrote: >>> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn >>> provides @SET_MAKE@ for substitution in Makefiles; >>> >> Right, I had forgotten about that. I somehow

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

On 01/03/2013 04:54 PM, Stefano Lattarini wrote: >> Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn >> provides @SET_MAKE@ for substitution in Makefiles; >> > Right, I had forgotten about that. I somehow just took it for granted > that it was all Automake's doing ... > > So

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

On 01/04/2013 12:35 AM, Bob Friesenhahn wrote: > On Fri, 4 Jan 2013, Stefano Lattarini wrote: > >> On 01/03/2013 11:53 PM, Nick Bowler wrote: >>> On 2013-01-03 23:05 +0100, Stefano Lattarini wrote: TARGETS = all check clean distclean dist distcheck install uninstall .PHONY: $(TA

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

On 01/04/2013 12:31 AM, Eric Blake wrote: > On 01/03/2013 03:05 PM, Stefano Lattarini wrote: > Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message to report the "quirky" role of $MAKE (patches welcome). >>> >>> I'll think about an automake patch to make it precio

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

On Fri, 4 Jan 2013, Stefano Lattarini wrote: On 01/03/2013 11:53 PM, Nick Bowler wrote: On 2013-01-03 23:05 +0100, Stefano Lattarini wrote: TARGETS = all check clean distclean dist distcheck install uninstall .PHONY: $(TARGETS) $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@ Unfortunately, th

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

On 01/03/2013 03:05 PM, Stefano Lattarini wrote: >>> Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message >>> to report the "quirky" role of $MAKE (patches welcome). >> >> I'll think about an automake patch to make it precious (at this point, >> I'm thinking that the use o

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

On 01/03/2013 11:53 PM, Nick Bowler wrote: > On 2013-01-03 23:05 +0100, Stefano Lattarini wrote: >> >> TARGETS = all check clean distclean dist distcheck install uninstall >> .PHONY: $(TARGETS) >> $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@ > > Unfortunately, this kind of wrapper doesn't work pa

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

On 2013-01-03 23:05 +0100, Stefano Lattarini wrote: > On 01/03/2013 10:34 PM, Eric Blake wrote: [...] > > Hmm, that goes back to one of the questions we asked about Automake-NG - > > is it possible to write a generic makefile that merely forwards all > > requests to gmake, and where all of the real

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

ther than making developers duplicate work? > >> In fact, is it possible to write a >> Makefile that compares the encoded settings of $(MAKE) set at configure >> time, against the current value of $(MAKE) from the current make >> implementation running the makefile, and

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

can even turn this Makefile into a Makefile.in, use '@GNU_MAKE@' rather than simply 'gmake', and (from configure) look for a GNU make implementation in the system and AC_SUBST '@GNU_MAKE@' to its absolute path. > In fact, is it possible to write a > Makefile

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

On 01/03/2013 01:57 AM, Karl Berry wrote: > OTOH, what about distribution "tarballs" in '.zip' format? They don't > use tar at all ... Time to deprecate them maybe? Is anybody actually > using them? And while at it, what about the even more obscure 'shar' > format? > > FWIW, I

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

On 01/03/2013 01:57 AM, Karl Berry wrote: > > that every tar (except maybe really ancient ones, can't remember, but we > > don't care) supports the -style. > > It would be nice to verify this claim on as much systems as possible > > Certainly POSIX has always required supporting -option

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

OTOH, what about distribution "tarballs" in '.zip' format? They don't use tar at all ... Time to deprecate them maybe? Is anybody actually using them? And while at it, what about the even more obscure 'shar' format? FWIW, I think they should still be supported. I see recent di

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

> that every tar (except maybe really ancient ones, can't remember, but we > don't care) supports the -style. It would be nice to verify this claim on as much systems as possible Certainly POSIX has always required supporting -options, which is some 15 years old at least. Or do I mea

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

That is already possible: I see. Given this, I propose merely changing the definition of am__tar to use variables. Something like: am__tar = $(TAR) $(TAR_OPTIONS) - "$$tardir" where the actual definitions of TAR

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

On Tue, 1 Jan 2013, Stefano Lattarini wrote: I don't propose any major surgery to make it work in every conceivable circumstance. All that is really necessary is to provide a way to pass --exclude-vcs to tar. It would only work with GNU tar, but that is ok. In GraphicsMagick I use find+cpio

bug#13324: Improvements to "dist" targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

Severity: wishlist Hi Karl. I'm adding bug-automake in CC, so that this discussion will remain visible and archived in a singe place, and we won't forget about the issue. On 01/01/2013 01:38 AM, Karl Berry wrote: > Stefano and all, > > It would be nice to able to list directories in EXTRA_DIST.

bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Quite a lengthy response for such a simple inquiry! Really, I'd just like to get gobject-introspection to compile on Arch Linux. The problem is that gobject-introspection's configure.ac has the line AM_PATH_PYTHON([2.5]) but gobject-introspection can't actually work with Python 3 or higher (the

bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

>> > Me too, mostly. But I agree that there is an underlying issue (albeit > not major). > >> The "Future Changes to this Recommendation" >> section of PEP 394 anticipates changing the `python' symlink to >> `python3' at some point in the future. This has already happened in Parabola, Arch and ot

bug#13170: automake and pyconfigure: a future integration? (was: Re: [PATCH] AM_PATH_PYTHON: try "python2" et al. first)

Severity: wishlist [+cc bug-automake, +cc bug-pyconfigure] Reference: On 12/13/2012 11:15 AM, Jack Kelly wrote: > Kerrick Staley writes: >> Usually, when AM_PATH_PYTHON is invoked with an argument of the form >> 2.X, it

bug#12967: Texinfo compile failure on IRIX 6.5 (was: Re: failure on IRIX 6.5)

Has been IRIX discontinued? According to Wikipedia, IRIX 6.5 will be retired as of December 2013. k

bug#12967: Texinfo compile failure on IRIX 6.5 (was: Re: failure on IRIX 6.5)

[+cc bug-automake] Hi Patrice, Karl. On 11/23/2012 03:17 AM, Patrice Dumas wrote: > On Thu, Nov 22, 2012 at 05:52:50PM -0700, Karl Berry wrote: >> info do not compile on IRIX 6.5. There is an error linked with the >> call of depcomp. >> What is the dependency style determined by configur

bug#11401: Automake, Libtool and AM_PROG_AR (was: Re: bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR)

References: On 05/11/2012 01:37 PM, Stefano Lattarini wrote: > On 05/04/2012 09:19 PM, Mike Frysinger wrote: >> On Friday 04 May 2012 03:20:10 Peter Rosin wrote: >>> On 2012-05-0

bug#12845: [PATCH] aclocal: AC_CONFIG_MACRO_DIRS: work around autom4te option parsing bugs (was: Re: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well)

On 11/15/2012 11:58 AM, Stefano Lattarini wrote: > > The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS > with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 > and earlier though, due to a bug in autom4te option parsing (fixed by > autoconf commit v2.68-120-gf4b

bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well (was: Re: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks)

AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages. Are >> you arguing that tracing both macros is a bad idea? If yes, I might >> add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and >> AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detec

bug#12877: Autoconf, GNU m4 and POSIXLY_CORRECT (was: Re: bug#12877: automake error: unrequested trace '')

[+cc autoconf] On 11/14/2012 07:45 AM, Sebastian Freundt wrote: > Stefano Lattarini writes: > >> tags 12877 + moreinfo >> thanks >> >> Hi Sebastian, thanks for the report. >> >> On 11/13/2012 11:30 AM, Sebastian Freundt wrote: >>> shell> automake --version >>> automake (GNU automake) 1.12.1 >>>

bug#12845: aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_MACRO_DIRS (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

oconf 2.72 >> that is as of today used in half of all configure.ac files. [1] >> >> Did you ever consider the consequences e.g. for Debian, where more than >> thousand packages are re-running autoconf at package build time? >> "We have to fix 1000 packages before

bug#12219: Could the --add-missing option be supported in AM_INIT_AUTOMAKE? (was: Re: How to automatically get missing files when changing configure.ac?)

Severity: wishlist [CC:ing bug-automake so that I won't forget about this issue] On 08/17/2012 01:04 AM, Jeff Johnston wrote: > If a configure.ac file is edited and the following added: > > LT_INIT > AC_PROG_LIBTOOL > I think you shouldn't add both, BTW; AC_PROG_LIBTOOL is the obsolescent name f

bug#12041: Issues running the testsuite as root (was: Re: bug#12041: GNU Automake 1.12.2 - FAIL 4 tests on SunOS5.10_sparcv9_64-bit)

First comment : wow. that was fast. :-) - Original Message - From: Stefano Lattarini Date: Tuesday, July 24, 2012 8:48 am Subject: Issues running the testsuite as root (was: Re: bug#12041: GNU Automake 1.12.2 - FAIL 4 tests on SunOS5.10_sparcv9_64-bit) To: Dennis Clarke Cc: 12

bug#12041: Issues running the testsuite as root (was: Re: bug#12041: GNU Automake 1.12.2 - FAIL 4 tests on SunOS5.10_sparcv9_64-bit)

severity 12041 minor retitle 12041 Issues running the testsuite as root thanks Hi Dennis, thanks for the report. On 07/24/2012 02:25 PM, Dennis Clarke wrote: > > > n.b.: see attached self-check-exit.log.gz > and GNU_Automake_1.12.2_SunOS5.10_sparcv9_64-bit.test.log.gz > and GNU_Aut

bug#11942: Oops, spurious report, ignore (was: Re: bug#11942: ylwrap appears not to support bison's lalr1.cc skeleton)

retitle 11942 Oops, spurious report, ignore tags 11942 notabug close 11942 thanks While replying to an old bug report, I've opened a new one by mistake. I'm closing it now. Sorry for the noise, Stefano

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules (was: Re: FYI: maint: fix the generation of the synclines for bison's parser)

Le 6 mai 2012 à 12:38, Stefano Lattarini a écrit : > Severity: wishlist > > [Adding bug-automake in CC:] > > Hi Akim. > > On 05/06/2012 11:20 AM, Akim Demaille wrote: >> This is taken from master. I work with a VPATH build, and the >> generated synclines are very wrong. Probably something th

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules (was: Re: FYI: maint: fix the generation of the synclines for bison's parser)

Severity: wishlist [Adding bug-automake in CC:] Hi Akim. On 05/06/2012 11:20 AM, Akim Demaille wrote: > This is taken from master. I work with a VPATH build, and the > generated synclines are very wrong. Probably something that > ylwrap should handle better btw. > Or maybe we could get rid of

bug#11030: [FYI] {maint} install-mans: avoid spurious failure with NetBSD make (was: Re: bug#11030: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"?)

On 03/18/2012 08:19 PM, Stefano Lattarini wrote: > tags 11030 + patch > close 11030 > thanks > > On 03/18/2012 08:03 AM, Stefano Lattarini wrote: >> >>> On 03/16/2012 11:04 PM, Stefano Lattarini wrote: You have convinced me that this behaviour is more a bug than a feature. >>> And h

bug#10866: [FYI] tests: fix spurious failure due to exported MAKEINFO (was: Re: bug#10866: 1.11a OSX with llvm - 3 fails, 47 skips, 3 errors, out of 2856 tests)

On 03/01/2012 10:45 PM, P. Martin wrote: > FAIL: txinfo30 > == > > Running from installcheck: no > Using TAP: no > PATH = /private/tmp/homebrew-automake-HEAD-DUdI/tests/ax:... > ++ pwd > /private/tmp/homebrew-automake-HEAD-DUdI/tests/txinfo30.dir > + echo info_TEXINFOS = bar.texi > + e

bug#10866: [FYI] tests: fix spurious failure in a vala test (was: Re: bug#10866: 1.11a OSX with llvm - 3 fails, 47 skips, 3 errors, out of 2856 tests)

On 03/01/2012 10:45 PM, P. Martin wrote: > FAIL: vala-mix2 > === > > Running from installcheck: no > Using TAP: no > PATH = /private/tmp/homebrew-automake-HEAD-DUdI/tests/ax:... > vala-mix2: running valac --version > Vala 0.15.2 > vala-mix2: determine whether make is GNU make > GNU Mak

bug#8880: [PATCH] tests: fix spurious failure when dependency tracking is unavailable (was: Re: bug#8880: [PATCH] add pgcc support to depcomp)

On 02/27/2012 11:01 PM, Dave Goodell wrote: > "yacc-dist-nobuild.dir" fails without this depcomp patch, but it passes with > it. I didn't fully grok this test, but it looks like the test requires > dependency support from the compiler+depcomp to operate correctly. > Not really, that was a redundan

bug#10859: [PATCH] tests: looks for GNU compilers at configure time (was: Re: bug#10859: AC_PROG_CC mistaken clang for GCC)

[Dropping bug-autoconf] Reference: On 02/21/2012 10:52 PM, Stefano Lattarini wrote: > > Now that we have identified the problem, fixing it shouldn't be too difficult; > I will follow-up in the next days with a patch. > Here it is (for master).

bug#10859: AC_PROG_CC mistaken clang for GCC (was: Re: bug#10859: 1.11a head on OSX Lion with Clang - 173 fails 87 skips of 2854 tests)

[CC:ing bug-autoconf] Reference: On 02/21/2012 09:44 PM, Panther Martin wrote: > >> On Feb 20, 2012, Stefano Lattarini wrote: >> >> Hmm... this doesn't ring a bell right away, even after I've looked into the >> attached logs. Could you pl

bug#10473: [PATCH] automake: new option to print locations of scripts and data files (was: Re: bug#10473: Run automake to create config.sub without any Makefile.am)

retitle 10473 get directory holding automake-provided scripts and data files severity 10473 wishlist tags 10473 patch thanks [dropping autoc...@gnu.org] On 01/10/2012 10:57 PM, Mike Frysinger wrote: > On Tuesday 10 January 2012 16:10:29 Nick Bowler wrote: >> On 2012-01-10 15:41 -0500, Mike Frysin

bug#10825: Better bison support in Automake (was: Re: FYI: master: calc++: rely on Automake)

Le 16 févr. 2012 à 11:21, Stefano Lattarini a écrit : > Hi Akim. Hi! > Thanks, fixed (see attached patch). > >> But maybe automake no longer needs this? >> > It still need it; without that, no header file will be generated from > the '.y' files (this is a feature, not a bug). > >> If it does

bug#10825: Better bison support in Automake (was: Re: FYI: master: calc++: rely on Automake)

[CC:ing bug-automake, so that we won't forget about the issues raised here] Hi Akim. On 02/15/2012 01:31 PM, Akim Demaille wrote: > > Le 15 févr. 2012 à 13:18, Stefano Lattarini a écrit : > >> On 02/15/2012 11:36 AM, Akim Demaille wrote: >>> Rely on $(YACC) being the bison being built, and let

bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines (was: Re: bug#10427: coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1)

[adding bug-automake in CC:] Reference: Hi Paul, thanks for the report and diagnosis. On 01/05/2012 10:00 AM, Paul Eggert wrote: > The latest coreutils snapshot fail to build > >> On 01/03/2012 06:10 PM, Jim Meyering wrote: >>> FYI, here's

bug#10436: New testsuite driver and extra trailing backslash in recipes (was: Re: bug#10427: coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1)

[adding bug-automake in CC:] Reference: Hi Paul, thanks for the report and diagnosis. On 01/05/2012 10:00 AM, Paul Eggert wrote: > I'm sending this to bug-automake because I think it's an automake > issue. However, the problem causes the la

bug#9238: "make dist" when "." is in SUBDIRS (was: Re: help help2man to find iwhd)

retitle 9238 "make dist" when "." is in SUBDIRS severity 9238 minor thanks References: Hi Jim, sorry for the delay. Jim Meyering wrote: > > I took a look at the generat

bug#10411: Add support for user-defined compressors (was: Re: Automake 1.11.2 released)

Severity: whishlist thanks On 12/27/2011 08:21 PM, Antonio Diaz Diaz wrote: > Hello Bob, and thanks. > > Bob Friesenhahn wrote: >> >> The approach that lzip used satisifies the standard GNU-mandated >> configuration requirements. Due to using only standard C++, it only >> needs to configure aspe

bug#10374: depmod.tap failures on master (was: Re: bug#10374: 3 test failures on fedora 16)

On 12/26/2011 11:26 PM, Jim Meyering wrote: > FAIL: depmod > FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake > FAIL: depmod.tap 84 - tru64 [absolute VPATH] make & remake > Known long-standing failures; see:

bug#10301: Problems in $(LIBTOOL) deifnition (was: Re: automake bug#10301: /bin/sh used to execute libtool)

On 15 December 2011 11:54, Stefano Lattarini wrote: >> >> I'm cross-compiling gettext to mingw32-target in linux system. I have >> to regenerate build system (so it's not the one distributed with >> gettext 0.18.1.1). I end with libtool-script that has /bin/bash as >> shebang. Yet when doing the b

bug#10301: Problems in $(LIBTOOL) deifnition (was: Re: automake bug#10301: /bin/sh used to execute libtool)

[CC:ing bug-libtool] Hi Marko, thanks for the report. On Wednesday 14 December 2011, Marko Lindqvist wrote: > I'm not entirely sure if this is automake or libtool bug, but assuming > automake so reporting here. > > I'm cross-compiling gettext to mingw32-target in linux system. I have > to regener

bug#10026: [PATCH] texinfo: work around Solaris 10 xpg4 shell bug in install rules (was: Re: bug#10026: branch-11.1 testsuite on Solaris 10 [3] (XPG4 sh, Sun Studio compilers, autoconf 2.62) [almost O

On Saturday 19 November 2011, Stefano Lattarini wrote: > On Saturday 12 November 2011, Stefano Lattarini wrote: > > SETUP: > > Solaris 10, "rich /usr/local" (e.g., contains `expr' from GNU coreutils > > 6.9 and gawk 3.1.5), VPATH build, perl 5.10.0, autoconf 2.62, testsuite > > run with GNU m

bug#10026: [PATCH] texinfo: work around Solaris 10 xpg4 shell bug in install rules (was: Re: bug#10026: branch-11.1 testsuite on Solaris 10 [3] (XPG4 sh, Sun Studio compilers, autoconf 2.62) [almost O

On Saturday 12 November 2011, Stefano Lattarini wrote: > SETUP: > Solaris 10, "rich /usr/local" (e.g., contains `expr' from GNU coreutils > 6.9 and gawk 3.1.5), VPATH build, perl 5.10.0, autoconf 2.62, testsuite > run with GNU make 3.82, test scripts run by /usr/xpg4/bin/sh, > $CONFIG_SHELL

bug#9807: custom libtool installation and automake testsuite failures (was: Re: [PATCH] tests: avoid false positive due to change in --help formatting)

Hi Jim. On Sunday 06 November 2011, Jim Meyering wrote: > Stefano Lattarini wrote: > > On Friday 04 November 2011, Stefano Lattarini wrote: > >> On Friday 04 November 2011, Stefano Lattarini wrote: > >> > > >> > [SNIP] > >> > > >> > Attached is a patch in this spirit; I'll push in a few hours if t

bug#8434: New public branch "java-work" (was: Re: [PATCH] java: allow both dist_JAVA and nodist_JAVA in the same Makefile.am)

Reference: On Saturday 23 April 2011, Stefano Lattarini wrote: > On Monday 18 April 2011, Stefano Lattarini wrote: > > On Saturday 09 April 2011, Ralf Wildenhues wrote: > > > Hi Stefano, > > > > > > * Stefano Lattarini wrote on Wed, Apr 06, 201

bug#9512: TEXINFOS primary and nodist_ (was: Re: makeinfo in VPATH builds fails)

Submitter: Sebastian Freundt thanks Reference: On Thursday 15 September 2011, Sebastian Freundt wrote: > Stefano Lattarini writes: > > > The main point is that if you're distributing you `.info' files, you should > > ensure that they are *not

bug#7648: Automake yacc support, GNU bison, and non-standard generated headers (was: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton)

Hi Stefano, On 2011-05-12, Stefano Lattarini wrote: > I decided that, after all, the best thing to do was to rewrite the > messy ylwrap script; after some work, I've now reached a point where I > think we could safely add, without too much hassle, a new feature, > that will allow the developer to

bug#9037: distcheck should check for missing m4 files too (was: Re: bug#9026: Supporting $ACLOCAL_PATH?)

On Saturday 09 July 2011, Peter Johansson wrote: > Hi Bruno, > > On 7/8/11 5:24 PM, Bruno Haible wrote: > > +If you are using GNU @code{automake} 1.10 or newer, it is even easier: > > +Add the line > > + > > +@example > > +ACLOCAL_AMFLAGS = --install -I m4 > > +@end example > > + > > +@noindent >

bug#8784: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS (was: Re: bug#8784: Support developer-reserved AM_DISTCHECK_CONFIGURE_FLAGS)

On Friday 10 June 2011, Stefano Lattarini wrote: > Reference: > > > On Thursday 02 June 2011, Stefano Lattarini wrote: > > Severity: wishlist > > > > Hello automakers. > > > > Continuing with the good trend of avoiding to impinge on the user >

bug#8784: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS (was: Re: bug#8784: Support developer-reserved AM_DISTCHECK_CONFIGURE_FLAGS)

Reference: On Thursday 02 June 2011, Stefano Lattarini wrote: > Severity: wishlist > > Hello automakers. > > Continuing with the good trend of avoiding to impinge on the user > namespace, we should start supporting AM_DISTCHECK_CONFIGURE_FLAGS

bug#8599: upc (Unified Parallel C) support in automake (was: Re: AM_PROG_UPC)

Hi Stefano On 4/30/11 1:10 PM, "Stefano Lattarini" wrote: >[adding automake and bug-automake lists] >[follow-ups might drop autoconf list IMHO] >[Reference: >] > >Hello Justin and Ralf, and sorry for the delay. > >On Saturday 30

bug#8599: upc (Unified Parallel C) support in automake (was: Re: AM_PROG_UPC)

[adding automake and bug-automake lists] [follow-ups might drop autoconf list IMHO] [Reference: ] Hello Justin and Ralf, and sorry for the delay. On Saturday 30 April 2011, Justin wrote: > On 4/29/11 8:57 PM, "Ralf Corsepius" wro

  1   2   3   4   5   6   7   8   9   10   >