bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

On 2023-12-19 14:54, Karl Berry wrote: Hi Paul, help2man: can't get `--help' info from bin/automake Try `--no-discard-stderr' if option outputs to stderr So, the obvious question is, why can't help2man run bin/automake? Clearly it works on other systems, and it doesn't seem like this

bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

Here are the symptoms. But now that I look into it, I see the automake-1.16 build fails with the same symptoms. So I assume this is low priority. GEN doc/automake-1.16.1 help2man: can't get `--help' info from bin/automake Try `--no-discard-stderr' if option outputs to stderr *** Error

bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)

into Automake. The original bug was fixed before I got to this, so I'm boldly closing the bug report.From 668e8a20e3561063ee7478e91c9f81bb40cfed7a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 2 Dec 2023 21:50:45 -0800 Subject: [PATCH] Simplify recent $PERL check MIME-Version: 1.0 Content

Re: rhel8 test failure confirmation? [PATCH for problem affecting Automake testsuite]

e.From 713d9822bbfb2923115065efaefed34a0113f8a1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 1 Apr 2023 16:44:03 -0700 Subject: [PATCH] Fix timing bug on high-speed builds MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Bogdan via Jacob Bachmeyer in:

bug#61671: Remove parentheses around test argument lists

Thanks, I installed that patch into Automake.

bug#61670: [PATCH] Improve test for blocked signals

Thanks, I installed that patch into Automake.

[bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

Thanks for the explanation. I installed those two patches into Automake.

[bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

On 2023-03-28 08:21, Warren Young wrote: Surely Solaris 10 (shipped in 2005) is relegated to the role of porting target, getting nothing but a “dist” tarball? Good point. I'll cc this to Dagobert Michelsen, who maintains the Autoconf port for Solaris 10. Dagobert, are people still running

[bug#61240] improve high-res file timestamp in Automake

On 2023-02-05 21:43, Jacob Bachmeyer wrote: Should the patch be relative to commit 6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version requirement bump) or should it include reverting commit 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)? Might as well do

[bug#61240] improve high-res file timestamp in Automake

On 2023-02-05 17:14, Jacob Bachmeyer wrote: How often is Perl built to use long doubles these days?  (That was an option beginning with Perl 5.6.) I doubt it's used much. It's not used in Ubuntu or Fedora, for what it's worth. And on some platforms (e.g., macOS on current Apple silicon)

[bug#61240] improve high-res file timestamp in Automake

On 2023-02-04 16:02, Jacob Bachmeyer wrote: In any case, you will still need to account for the possibility that Time::HiRes::stat() might not actually have higher resolution, depending on the filesystem. That's fine. All we want is the exact file timestamp. If the file system timestamp

[bug#61240] improve high-res file timestamp in Automake

On 2023-02-03 18:27, Jacob Bachmeyer wrote: Where are you actually using a 5.10 feature? Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This does not work with Perl 5.6. For why we bumped the version to 5.10, please see:

[bug#61240] improve high-res file timestamp in Automake

don't think that's a problem nowadays.From 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 2 Feb 2023 14:13:24 -0800 Subject: [PATCH 1/2] maint: require perl 5.010 or later This is needed for better treatment of high-res timestamps. --- NEWS

Re: portability of xargs

On 2/14/22 20:03, Mike Frysinger wrote: are the corner cases known ? I don't know of a catalog, no. These days you might have better luck with "find ... -exec ... {} +". Although standardized more recently than xargs, my vague impression is that there's less variation among implementations.

Re: portability of xargs

On 2/14/22 19:45, Mike Frysinger wrote: how portable is xargs ? It can be a porting problem, unfortunately. There are several corner cases that various implementations don't get right. I expect this is why the GNU Coding Standards exclude xargs from the list of programs that 'configure' and

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/11/21 4:03 AM, Kiyoshi KANAZAWA wrote: Failures of flex's make check also disappeared with bison-3.8.1. Thanks for testing, and thanks Akim for writing the patch. I installed it on the automake master branch on Savannah.

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/8/21 2:18 PM, Karl Berry wrote: Just an idea that I don't expect you to adopt, but just to mention -- you could only institute the breaking change if POSIXLY_CORRECT. That's why POSIXLY_CORRECT exists. -k I like this idea. It insulates us against POSIX decisions and/or indecisions in

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/7/21 10:31 PM, Akim Demaille wrote: However, I don't see a published version of the POSIX Yacc "specs" that includes these changes. The next POSIX revision is targeted for 2022, according to . I suppose there is still opportunity

Re: config.sub/config.guess using nonportable $(...) substitutions

On 3/9/21 12:26 PM, Paul Eggert wrote: On 3/9/21 11:09 AM, Karl Berry wrote: I fully disagree. (Along with, it seems, everyone else except you and Ben.) Ben is the main person to convince here, since he's the maintainer. Oh, my mistake. Ben has stepped down, so I should have written

Re: config.sub/config.guess using nonportable $(...) substitutions

On 3/9/21 11:09 AM, Karl Berry wrote: I fully disagree. (Along with, it seems, everyone else except you and Ben.) Ben is the main person to convince here, since he's the maintainer. I am a bit disenheartened to see that Ben hasn't sent any email to this list since he installed the change in

Re: config.sub/config.guess using nonportable $(...) substitutions

On 3/9/21 5:57 AM, Bob Friesenhahn wrote: It seems that config.guess and Autotools packages are picking winners and losers.  It is not clear where the bar has been set. I prefer to draw the line at systems that are no longer supported by their own suppliers. For Solaris, that means I worry

Re: config.sub/config.guess using nonportable $(...) substitutions

On 3/8/21 3:00 PM, Dmitry V. Levin wrote: The only rationale provided by the previous maintainer so far is a short message in config-patches mailing list [1]. The config maintainer Ben Elliston has wanted to get rid of the old-fashioned accent graves for many years. In November 2017 he

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

On 1/29/21 12:03 PM, Zack Weinberg wrote: Perl 5.18.0 was released in May 2013. (Perl 5.6.0 was released in March 2000.) I selected it as the minimum because the Perl maintainers recommend all users of older interpreters upgrade to at least this version, due to security fixes (see

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On 1/28/21 10:34 AM, Zack Weinberg wrote: we could instead use the battle-tested technique used by Emacs: symlink sentinels. (See https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c .) Although that Emacs code is battle-tested, one of the things it does is fall back on regular

Re: Future plans for Autotools

On 1/21/21 8:01 AM, Zack Weinberg wrote: I know that at least one person has tried to write a set of GNU Make library files intended to replace it altogether, but I've never seen anyone *finish* that project. I'd very much like to see someone give that another go. GNU Emacs never used

Re: AC_DIAGNOSE not obsolete, please

On 10/6/20 10:31 AM, Zack Weinberg wrote: Seems reasonable. What do you think of the patches below? Those Autoconf patches look good to me, thanks.

Re: [RFC PATCH 0/6] Work around autoconf/automake warnings skew

On 9/22/20 1:04 PM, Zack Weinberg wrote: The main thing I want to discuss before merging these patches is the location of the new Perl function merge_WARNINGS. I put it in ChannelDefs.pm because that is where all the other code relating to WARNINGS is, but it’s only used in autoreconf, so

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

On 9/22/20 3:47 PM, Karl Berry wrote: Zack, the Automake changes look fine to me. Please commit/push at your convenience, as far as I'm concerned. Thanks!! They look good to me, too.

Re: Warning category skew between Autoconf and Automake - workaround in autoreconf?

On 9/10/20 11:48 AM, Zack Weinberg wrote: I’m wondering whether it would make sense to merge this distributor’s patch to avoid supplying -Wcross to automake -- perhaps generalized to arbitrary warning categories. What do you think? Yes, we can't assume that both packages are of the same

Re: problems with "make install" directory permissions

On 7/27/20 2:24 PM, Karl Berry wrote: https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html I can understand increasing permissions to allow +rx on installation directories, but why force 755, thus disallowing group writability? I've never understood this forcing of 755. I expect it

Re: problems with "make install" directory permissions

Automake master's install-sh and mkinstalldirs files, resulting in the attached Gnulib patch which I've installed into Gnulib master. Hope this helps. >From 1990797800153088f32029877f503f3157aad9ed Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 26 Jul 2020 15:17:46 -0700 Subject: [PA

bug#42051: Automake Bug

Although it's hard to tell from the symptoms, my guess is that it's some sort of issue with autom4te calling the wrong version of M4 (or maybe of Perl), or M4 not being installed in the right place in your VM, or something like that. Can you specify which version of RHEL you're using, and give

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On 4/13/20 4:21 PM, Harald van Dijk wrote: For better or worse, FAT is the most universally accepted file system, and for that reason it is widely used. It does not even support second precision timestamps. Let's not worry much about that. In practice, little development of Automake-using

Re: copyright problem with install-sh, request for clean-room rewrite

Mathieu Lirzin wrote: According to ‘git blame’ I appear to not have touch this file, so if you think that I am eligible, I am volunteering on this rewriting task. Thanks for volunteering. Eric, do you think it would save time overall if you sent him the part of install-sh that you are sure is

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

On 11/20/2017 11:44 PM, Bernhard Voelker wrote: So my question: aren't 3-level version strings allowed by the gnits check in combination with gnulib's git-version-gen script?  Do we have to change the strictness from gnits to gnu? I would think so, unless someone takes the time to change

[INSTALLED 2/3] install-sh: do not assume / = //

* lib/install-sh: Do not append / to destination directory if it already ends in /. This supports a destination directory of // on hosts where / and // are distinct directories, as POSIX allows. --- lib/install-sh | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff

[INSTALLED 1/3] maint: fix two more http: URLs

* m4/init.m4: Change http: to https: in comments. --- m4/init.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/m4/init.m4 b/m4/init.m4 index f788134a1..9024b3aaa 100644 --- a/m4/init.m4 +++ b/m4/init.m4 @@ -87,8 +87,8 @@ AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl

[INSTALLED 3/3] maint: update .gitignore

* .gitignore: Add pre-inst-env, and sort. --- .gitignore | 75 +++--- 1 file changed, 38 insertions(+), 37 deletions(-) diff --git a/.gitignore b/.gitignore index 56bdce2c6..89e71ec97 100644 --- a/.gitignore +++ b/.gitignore @@ -1,68 +1,69

Re: bug#20314: [PATCH] Make output of mdate-sh deterministic

On 09/22/2017 02:57 AM, Bruno Haible wrote: Gnulib also supports MSVC, which interprets the TZ environment variable in its own way [1][2]. From this doc and from POSIX [3], it looks to me that UTC0 GMT0 GMT+0 GMT-0 would all be equivalent and portable. Can you confirm this? All of

Re: bug#20314: [PATCH] Make output of mdate-sh deterministic

. For reference, here's the POSIX spec for TZ: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 and look for "TZ". From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Thu, 21 Sep 201

bug#20314: [PATCH] Make output of mdate-sh deterministic

. For reference, here's the POSIX spec for TZ: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 and look for "TZ". From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Thu, 21 Sep 201

Re: FTP,HTTP → HTTPS in Automake doc and code

Mathieu Lirzin wrote: IMO it is important that reflects that change too. AIUI this page serves as a model for GPL license notices. Yes, that would be good. Unfortunately I don't know who's in charge of that URL.

FTP,HTTP → HTTPS in Automake doc and code

I installed into Automake 'master' a patch to prefer https: URLs to ftp: and http: URLs. It's a long patch so I won't bore the mailing list with it. Details and justification are here: https://git.savannah.gnu.org/cgit/automake.git/commit/?id=199e7a445040270fa5ef67623c56cde40d765199

Re: [PATCH v3] new option: object-shortname

On 12/22/2016 06:38 AM, Thomas Martitz wrote: this is one more attempt to get my patch reviewed. Can I assist in any way? Well, what we really need is an Automake maintainer, to do this sort of review work. Is that something you'd be willing to do (and be qualified for)? It's not a job to

Re: [PATCH v3] new option: object-shortname

Thomas Martitz wrote: I thought you'd review and merge. It might be me at some point. Just not today, I'm afraid.

Re: [PATCH v3] new option: object-shortname

Thomas Martitz wrote: Please tell me if there's anything left for me to do? Not that I know of; someone needs to free up enough cycles to review it, that's all.

Re: bug#22702: [bug-grep] grep-2.23 build feedback

Jim Meyering wrote: I actually wrote a patch to fix the automake bug that led to this, but did not find the time to write a stand-alone test case. Today, I wrote the commit log entry and am attaching the incomplete diff (no NEWS and no test) here, in case someone wants to help move this along

Re: [PATCH v2] new option: object-shortname

Some minor comments: + - This option affects the file name automake uses for object files. + +Enabling the option shortens the file name such that the prefix +derived (after canonicalization) from the path is not included. For +instance, it is always foo-foo.o regardless of the

Re: [PATCH] new option: object-shortname

Have you looked at the similar change that is planned for Automake 1.16? To build that, you can do this: git clone -b minor git://git.savannah.gnu.org/automake.git cd automake ./bootstrap.sh ./configure --prefix=/your/favorite/directory make Assuming your needs aren't satisfied already by

bug#21219: automake: m4/python.m4: support python3.4 and python3.5

On 04/22/2016 06:46 AM, Thomas Klausner wrote: Thanks. I don't see the commit onhttp://git.savannah.gnu.org/cgit/automake.git yet though? http://git.savannah.gnu.org/cgit/automake.git/log/?h=micro We can also close my bug report 21219

[PATCH] maint: port time-stamp-time-zone to strict POSIX

Set time-stamp-time-zone to "UTC0", not to "UTC", as POSIX defines TZ="UTC0" not TZ="UTC". --- contrib/tap-driver.pl | 2 +- lib/compile | 4 ++-- lib/depcomp | 4 ++-- lib/install-sh| 4 ++-- lib/mdate-sh | 4 ++-- lib/missing | 4 ++--

bug#20132: [PROPOSED PATCH] autoconf: port better to future gzip

* lib/am/distdir.am (dist-gzip, dist-shar, distcheck): Port better to future versions of gzip, which are planned to deprecate the GZIP environment variable. --- lib/am/distdir.am | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/lib/am/distdir.am

bug#19616: [Bug-tar] dist tarball contains hardlinks

Dimitrios Apostolou wrote: But when the tarball is extracted, two files with same inode are created, which is kind of unexpected behaviour - at least for me Other utilities have similar behavior (e.g., ls, cp, du), in that they pretend the symlink isn't there and behave as if the pointed-to

bug#19616: [Bug-tar] dist tarball contains hardlinks

Dimitrios Apostolou wrote: Why is such behaviour desirable? It's more logical, since it causes tar to behave as if the symlink were not there, and the pointed-to file was there instead. Using -hard-dereference bloats the tar image, but if that's a price you're willing to pay then you have

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

Thanks, I installed the attached patch, which has the more-usual approach of a uniquely-named temporary. From 28b4fdb0ea4c540f1b7bcb90675e365e3aa11beb Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Sat, 23 Aug 2014 07:55:28 -0700 Subject: [PATCH] build: fix race in parallel

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

Stefano Lattarini wrote: please push (to the 'micro' branch) and close this bug report once you're done Thanks, done.

Re: bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

Stefano Lattarini wrote: please push (to the 'micro' branch) and close this bug report once you're done Thanks, done.

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

* doc/automake.texi: Specify @documentencoding and @documentlanguage, to prevent encoding errors for parts of this input file that are UTF-8. This also causes the .info output to use curly quotes, which is easier to read though it does assume UTF-8 support. --- doc/automake.texi | 2 ++ 1 file

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/16/13 04:46, Stefano Lattarini wrote: Makes sense. Should I try to implement something along these lines (might take a few days), or are you planning to do that yourself (in which case I'll avoid the duplicated efforts)? I wasn't planning on doing that, so please go ahead.

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/13 02:24, Stefano Lattarini wrote: Autoconfers, WDYT? I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378 is a long thread.

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/2013 11:56 AM, Stefano Lattarini wrote: 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc' or 'clang') supports -c -o together. Why? If the user has a broken base vendor compiler, but has installed a better one (say GCC), why should he still be

Re: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/13 02:24, Stefano Lattarini wrote: Autoconfers, WDYT? I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378 is a long thread.

Re: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/2013 11:56 AM, Stefano Lattarini wrote: 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc' or 'clang') supports -c -o together. Why? If the user has a broken base vendor compiler, but has installed a better one (say GCC), why should he still be

bug#12578: depcomp typo informations

On 10/14/2012 02:49 AM, Stefano Lattarini wrote: However, for the future, might I ask you to provide complete patches, even for trivial fixlets like this one? That would make the workflow easier for me. Sure. Even less work for you (and for me) would be if I simply applied the patches.

bug#12578: depcomp typo informations

There is no word informations in English. I found this typo while spell-checking Emacs, and want to fix the bug upstream, in Automake. diff --git a/lib/depcomp b/lib/depcomp index 0544c68..ee84bf2 100755 --- a/lib/depcomp +++ b/lib/depcomp @@ -108,7 +108,7 @@ if test $depmode = msvc7msys; then

Re: Python macros

My kneejerk reaction is that Python would be a good language for Autoconf to deal with. The hard part would probably be writing the documentation -- is that something you could do? The idea would be to come up with a patch to the Autoconf sources.

Re: [FYI] {master} maint: assume 'test -x' is portable

It's been Quite Some Time since I've had to deal with 4.3BSD, or any host with a test -x problem, so I suggest the following patch to the Autoconf manual: diff --git a/doc/autoconf.texi b/doc/autoconf.texi index 607d8dc..443ec07 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -18125,9

bug#10443: [PATCH] Quote 'like this', not `like this'.

files directly from Automake master, so here is a proposed patch to Automake master so that these files use the straight-up style. This patch affects only commentary and quoting in diagnostics. From f78c4d9a1fc2705badae4ce4ebf46d5d1c8209e0 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg

bug#10443: [PATCH] Quote 'like this', not `like this'.

On 01/06/12 02:00, Stefano Lattarini wrote: please send patches that don't fix any existing bug to the automake-patches Sorry, I'll try to remember that. assuming you have already re-run the whole testsuite with your changes applied, which you have, right?) Yes, I have now, on a Fedora 15

bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines

On 01/05/12 06:07, Stefano Lattarini wrote: Which sort of thing exactly? I could find only one place which suffers of the problem you've pointed out, i.e., the `recheck recheck-html' rules in lib/am/check.am. Am I missing something? Sorry, that appears to have been a miscount on my part: I

bug#10436: bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes

I pushed the following doc fix into Autoconf, so that these two portability issues are documented there. It turns out that the second issue is actually due to an old Bash bug -- it's not Solaris-specific. From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes

I pushed the following doc fix into Autoconf, so that these two portability issues are documented there. It turns out that the second issue is actually due to an old Bash bug -- it's not Solaris-specific. From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: [PATCH] drop Win32 term

On 01/04/12 05:37, Stefano Lattarini wrote: Care to fix those too? Here's a revised version of Bruno's patch that attempts to address all the issues that you raised. From ef5461d37207a965217e1b09c8ef257622f9d43c Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Wed, 4 Jan 2012

bug#7893: HP-UX make causes autoconf timestamp issues

That issue is now documented in the INSTALL file, as well as in the Autoconf manual. Here's the relevant commit: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=2d082fa1ca25a16b60fb874e80f51ee79408e1f4

Re: AM_SILENT_RULES does not work with NonStop make

On 12/26/11 13:35, Stefano Lattarini wrote: testing on non-Linux systems (*BSD and Solaris at least, hopefully also Cygwin or MinGW). I tested it on Solaris 8 and that test worked fine. I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'. Some of the other tests failed, e.g.,

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/26/11 09:42, Stefano Lattarini wrote: And here is the follow-up tweaking for the test cases I had promised. I will push in a couple of days if there is no objection. Thanks, that looks good to me; please push it as soon as you like.

Re: bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/26/11 09:42, Stefano Lattarini wrote: And here is the follow-up tweaking for the test cases I had promised. I will push in a couple of days if there is no objection. Thanks, that looks good to me; please push it as soon as you like.

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/23/11 00:50, Stefano Lattarini wrote: could you apply the patch *not to maint nor to master*, but to a *new* branch (say `silent-fixes' or `silent-portability') based off of maint, and push that new branch to the public automake repo? OK, done, as 'silent-fixes', with your recent

Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/23/11 00:50, Stefano Lattarini wrote: could you apply the patch *not to maint nor to master*, but to a *new* branch (say `silent-fixes' or `silent-portability') based off of maint, and push that new branch to the public automake repo? OK, done, as 'silent-fixes', with your recent

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 11:02, Stefano Lattarini wrote: If you are interested in accomodating this fringe situation, I will then accept a patch on the lines Paul has proposed (with a mandatory testcase, otherwise it would be far too easy to regress in such a almost-never-excercised corner case). OK, a

bug#10237: AM_SILENT_RULES does not work with NonStop make

If AM_SILENT_RULES is used, Automake generates Makefile.in files with lines like this: AM_V_CC = $(am__v_CC_$(V)) am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY)) and these are copied into Makefile unchanged. Unfortunately, as the Automake documentation notes, these lines do not conform to

bug#10237: bug#10234: Coreutils incompatibility with POSIX make

On 12/06/11 09:36, Jim Meyering wrote: I am very reluctant to sacrifice the above default solely to accommodate that system. Yes, the make chatter is annoying, but on the other hand being portable is pretty important too. It's not just NonStop; NextStep 'make' has a similar problem, and I

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 10:19, Stefano Lattarini wrote: which will also very likely be in the next POSIX standard, if I'm not mistaken) Do you have a reference for that? That would allay some of my concerns in this area, moving forward. I'm extremely reluctant to add yet more complexity to automake I

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 15:16, Daniel Richard G. wrote: (Paul: Does $({}) work on NonStop?) I don't know, sorry. I wanted a solution that worked on any POSIX platform -- POSIX 2008 says that $(aaa${bbb}) is just as unspecified as $(aaa$(bbb)) is, and I wanted to play it safe. Part of this is my experience

bug#10210: [PATCH] lib/depcomp: spelling fix in usage message

Found while spell-checking Emacs. Here's a proposed patch. There are similar misspellings in the ChangeLogs but that's less important. depcomp: spelling fix * lib/depcomp (-h): Fix misspelling in usage diagnostic. diff --git a/lib/depcomp b/lib/depcomp index 9825d56..b97ed64 100755 ---

bug#10083: [PATCH] * lib/install-sh: Spelling fix in comment.

@@ -1,3 +1,7 @@ +2011-11-19 Paul Eggert egg...@cs.ucla.edu + + * lib/install-sh: Spelling fix in comment. + 2011-11-10 Stefano Lattarini stefano.lattar...@gmail.com tests: avoid a spurious failure of 'ltinit.test' MinGW diff --git a/lib/install-sh b/lib/install-sh index a9244eb

bug#10083: Acknowledgement ([PATCH] * lib/install-sh: Spelling fix in comment.)

I pushed this as trivial (thanks to Jim), and am closing it.

bug#8493: autoconf fails if env var U set

On 04/13/2011 11:02 AM, Tom Lane wrote: If the intended use is only for ansi2knr, I'd even argue that it should be off by default ... how many people care about ansi2knr anymore? Nobody. It would be fine to remove the ansi2knr stuff from Autoconf.

Re: Patch proposal: Add --clean options to unbootstrap a project.

Ralf Wildenhues [EMAIL PROTECTED] writes: + xsystem (rm -rf '$cache') This won't work well if $cache contains an apostrophe. I realize this sort of problem is not new to the patch, but while we're making changes in this area, why not fix it? Either check for and reject cache names

Re: automatic update Makefile.am - Makefile.in - Makefile no longer working

Ralf Wildenhues [EMAIL PROTECTED] writes: I think this should be applied to HEAD and branch-1-10. Would you like me to do it? Yes, please. And thanks for your review; your points all look right to me. So this is yet another reason to keep Autoconf version incompatibilities as few as

Re: automatic update Makefile.am - Makefile.in - Makefile no longer working

Bruno Haible [EMAIL PROTECTED] writes: Are we now supposed to edit Makefile.in by hand each time we modify Makefile.am? I hope not. How about the following (untested) Automake patch? 2007-06-20 Paul Eggert [EMAIL PROTECTED] * aclocal.in (write_aclocal): Warn about autoconf

Re: M4 syntax $11 vs. ${11}

Eric Blake [EMAIL PROTECTED] writes: + /* This warning must not kill m4 -E, or it will break autoconf. */ + if (text strstr (text, ${)) +M4ERROR ((0, 0, Warning: raw `${' in defn of %s will change semantics, + name)); This warning will generate a lot of false positives,

Re: 1.10a instspc.test failure

Ralf Wildenhues [EMAIL PROTECTED] writes: 2007-01-17 Ralf Wildenhues [EMAIL PROTECTED] * doc/autoconf.texi (Setting Output Variables): Mention that all non-NUL characters are ok in substituted values. * lib/autoconf/status.m4 (_AC_SED_CMD_LIMIT): Fix comment typo.

Re: 1.10a instspc.test failure

Ralf Wildenhues [EMAIL PROTECTED] writes: -is called. The value can contain newlines. +is called. The value can contain all ASCII characters except for +the @code{NUL} character and carriage return; newline is ok to use. If we can assume POSIX conformance with a reasonable C locale, the

Re: ``install -C'' / unnecessarily updating time stamps

Ralf Wildenhues [EMAIL PROTECTED] writes: * tests/defs.in (is_newest): Cope with multiple newer files. * NEWS: mention `install-sh -C'. Thanks, please apply.

Re: ``install -C'' / unnecessarily updating time stamps

Benoit Sigoure [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html I installed the following to Automake install-sh to implement install-sh -C, which is the second part of that patch. 2006-12-25 Paul Eggert [EMAIL PROTECTED] * lib

Re: ``install -C'' / unnecessarily updating time stamps

Thomas Schwinge [EMAIL PROTECTED] writes: This brings up the following question: if `-C' shall be used a) by default in Autoconf's `AC_PROG_INSTALL' if available or b) if requested by the programmer through setting some flag, and `install-sh' supports `-C', but the system's `install'

Re: ``install -C'' / unnecessarily updating time stamps

Benoit Sigoure [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html I installed the following to Automake install-sh to implement install-sh -C, which is the second part of that patch. 2006-12-25 Paul Eggert [EMAIL PROTECTED] * lib

Re: ``install -C'' / unnecessarily updating time stamps

Benoit Sigoure [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html Sorry, I missed that one. The idea looks reasonable, but that solves the problem for install-sh only, right? GNU 'install' still wouldn't support -C. Also, the updated patch

Re: ``install -C'' / unnecessarily updating time stamps

. It shouldn't change any behavior. I installed this. I'll look into the -C part shortly. 2006-12-24 Paul Eggert [EMAIL PROTECTED] * lib/install-sh: Fix typo in previous patch for handling --. Use more-consistent style for ';;'. Prefer || to if-then-else-:. * tests

  1   2   >