[PATCH v2] build: Automake fixes (in particular re-enabling 'gnu' strictness)

quired, but better play safe). * INSTALL: Delete, it's generated by 'autoreconf' anyway. * .gitignore: Add 'INSTALL'. * config/.gitignore: Add the newly automake-installed 'ar-lib'. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini --- Sorry

[PATCH] build: Automake fixes (in particular re-enabling 'gnu' strictness)

ortability from Automake 1.12 or later (this is also what forces us to require 1.12 or later, as that macro is not available in earlier Automake version; but that's OK, since 1.12 is one-and-a-half years old now). Finally, also move AM_PROG_CC_C_O near to the AC_PROG_CC call (not s

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

On 05/26/2013 10:20 PM, Paul Smith wrote: > On Sun, 2013-05-26 at 22:05 +0200, Stefano Lattarini wrote: >> On 05/26/2013 09:57 PM, Paul Smith wrote: >>> >>> [SNIP] >>> >>> Might be worthwhile checking the FreeBSD code for their make, to see if >&g

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

On 05/26/2013 09:57 PM, Paul Smith wrote: > > [SNIP] > > Might be worthwhile checking the FreeBSD code for their make, to see if > they do something like this. > Nope, Frank was right: when run in parallel mode, FreeBSD make unconditionally behaves like GNU make does with the '-O' option enabled (

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

On 05/26/2013 05:18 AM, Frank Heckenbach wrote: > (Sorry, I can't reply properly; I'm not subscribed, just saw the > message on the web archive.) > > Stefano Lattarini wrote: > >> Make run in parallel mode with output redirected to a regular file >> ca

Re: [bug #26596] MAKEFLAGS documentation tweak

On 05/23/2013 10:28 PM, Paul Smith wrote: > On Wed, 2013-05-22 at 22:09 +0200, Stefano Lattarini wrote: >> On 05/22/2013 06:56 PM, Paul Smith wrote: >>> I've reworked the MFLAGS / MAKEFLAGS generation to be more regular and >>> rigorous yesterday, for 4.0, and to pr

Make run in parallel mode with output redirected to a regular file can randomly drop output lines

The issue is present both in all of make 3.81, make 3.82 and make built from latest Git. Here is a script that demonstrates it: $ cat foo.bash #!/bin/bash cat > GNUmakefile <<'END' all := 0 1 2 3 4 5 6 7 8 9 default: $(all) $(all): @sleep 0.$$(($RANDOM % 10)); echo $@ END

Re: [bug #26596] MAKEFLAGS documentation tweak

On 05/22/2013 06:56 PM, Paul Smith wrote: > On Wed, 2013-05-22 at 17:42 +0200, Stefano Lattarini wrote: >> Hi Paul. >> >> On 05/22/2013 05:17 PM, Paul D. Smith wrote: >>> Follow-up Comment #1, bug #26596 (project make): >>> >>> Hm. I'm not sure

Re: [bug #26596] MAKEFLAGS documentation tweak

Hi Paul. On 05/22/2013 05:17 PM, Paul D. Smith wrote: > Follow-up Comment #1, bug #26596 (project make): > > Hm. I'm not sure why the immediate expansion has limited content. Is there > any purpose to this? Wouldn't it just be better to have the immediate > expansion resolve to the entire thin

Re: Output sync completed (?)

On 05/06/2013 02:30 AM, Paul Smith wrote: > Hi all. I've recently pushed changes to solve the last open issues that > I'm aware of with the --output-sync feature: > > * If command line printing is not suppressed ("@" is not used) the > command line is attached to the output. >

Re: possible solution for -Otarget recurse

On 05/05/2013 05:30 PM, Paul Smith wrote: > On Sun, 2013-05-05 at 11:11 +0200, Stefano Lattarini wrote: >> Sorry to add this only now, but I realized the failure is only >> reproducible if I run the testsuite with "make -j", as in "make -j8 >> check; and ev

Re: possible solution for -Otarget recurse

Hi Paul. On 05/05/2013 08:19 AM, Paul Smith wrote: > On Sun, 2013-05-05 at 00:44 +0200, Stefano Lattarini wrote: >> The test 'features/output-sync' now fails for me: >> >> Test timed out after 6 seconds >> Error running /storage/home/stefano/src/gnu/ma

[PATCH] docs: port manual to Texinfo 5.x

* doc/make.texi: Here. It was sufficient to change an '@itemx' into an '@item'. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini --- doc/make.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/make.texi b/doc/make.texi index ea5

Re: possible solution for -Otarget recurse

Hi Paul. On 05/05/2013 12:10 AM, Paul Smith wrote: > On Fri, 2013-05-03 at 12:55 -0400, Paul Smith wrote: >> Suppose we do this: if we're about to invoke a line marked recursive >> and we're in -Otarget mode, then before we run it we'll show the >> current contents of the temp file (using the norm

Re: [PATCH] cosmetics: fix few innocuous typos

On 05/04/2013 01:34 PM, Paul Smith wrote: > On Sat, 2013-05-04 at 11:52 +0200, Stefano Lattarini wrote: >> Ping? Any reason not to apply this trivial patch? > > You may have noticed, there's a lot going on right now... and I do have > an actually for-$$ job as well :-).

Re: [PATCH] cosmetics: fix few innocuous typos

On 04/30/2013 03:37 PM, Stefano Lattarini wrote: > Most of these were found using Lucas De Marchi's 'codespell' tool. > > * ChangeLog: Fix minor typos. > * ChangeLog.2: Likewise. > * README.Amiga: Likewise. > * TODO.private: Likewise. > * function.c: Likewise.

Re: Some serious issues with the new -O option

On 05/01/2013 05:26 PM, Eli Zaretskii wrote: > > Unfortunately, the delays are still here. > I can say they're no longer there *in my use case*; I haven't tested other use cases though. Hope this is sorted out soon... Thanks, Stefano ___ Bug-make mai

Re: Some serious issues with the new -O option

Hi Paul. On 05/01/2013 02:04 PM, Paul Smith wrote: > On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote: >> On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote: >>> On 04/30/2013 03:37 PM, Paul Smith wrote: >>>> Just to be clear, you're saying

Re: Change in $(MFLAGS) format breaks automake-generated rules

Hi Paul. On 05/01/2013 08:26 AM, Paul Smith wrote: > On Wed, 2013-05-01 at 00:59 +0200, Stefano Lattarini wrote: >># With make 3.82, compiled from official tarball: >>$ make -f- <<<'all:; @echo $(MFLAGS)' -I none >>-I none >> >>

Change in $(MFLAGS) format breaks automake-generated rules

Few automake-generated recipes have the necessity to determine at runtime whether a particular make mode/option is active (e.g., '-k' or '-n'). To do so, they analyze the content of the $(MFLAGS) make variable. But the exact format of this variable has been changed in the development version of G

Re: [PATCH 2/3] build: enable 'subdir-objects' and 'silent-rules' automake options

On 04/30/2013 05:11 PM, Stefano Lattarini wrote: > * configure.ac (AM_INIT_AUTOMAKE): Here. The future major Automake > version 2.0 (ETA about one, one and half year from now) will likely > enable them by default, so better prepare ourselves. > Please drop this patch. Enabling &#x

[PATCH 3/3] build: get rid of 'HAVE_ANSI_COMPILER' C preprocessor conditional

.template: Likewise. * configh.dos.template: Likewise. Signed-off-by: Stefano Lattarini --- ChangeLog | 13 + config.ami.template | 3 --- config.h-vms.template | 3 --- config.h.W32.template | 3 --- configh.dos.template | 3 --- configure.ac | 6 -- 6 files

[PATCH 0/3] Few patches for the build system of GNU make

The second patch requires the first (as silent rules were only introduced in automake 1.11). The third patch should be fully independent. Stefano Lattarini (3): build: require Autoconf >= 2.62 and Automake >= 1.11.1 build: enable 'subdir-objects' and 'silent-rules'

[PATCH 2/3] build: enable 'subdir-objects' and 'silent-rules' automake options

* configure.ac (AM_INIT_AUTOMAKE): Here. The future major Automake version 2.0 (ETA about one, one and half year from now) will likely enable them by default, so better prepare ourselves. Signed-off-by: Stefano Lattarini --- ChangeLog| 8 configure.ac | 2 +- 2 files changed, 9

[PATCH 1/3] build: require Autoconf >= 2.62 and Automake >= 1.11.1

ping GNU make from the Git repository. * configure.ac (AC_PREREQ): Require Autoconf 2.62 or later. (AM_INIT_AUTOMAKE): Require Automake 1.11.1 or later (1.11 had some serious bugs, and should not be used). Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini --- ChangeLog

Re: Some serious issues with the new -O option

; will still try to run the test scripts. > This would be horrific of course ;-) > Hm. > > On Tue, 2013-04-30 at 11:48 +0200, Stefano Lattarini wrote: >> So please don't ever make that option the default; if you really >> really want to, at least put in place some smart che

[PATCH] cosmetics: fix few innocuous typos

@@ +2013-04-30 Stefano Lattarini (tiny change) + + cosmetics: fix few innocuous typos + + Most of these were found using Lucas De Marchi's 'codespell' tool. + + * ChangeLog: Fix minor typos. + * ChangeLog.2: Likewise. + * README.Amiga: Likewise. +

Re: Duplicated "Entering/Leaving directory" when new option -O is used

On 04/30/2013 03:06 PM, Paul Smith wrote: > On Tue, 2013-04-30 at 11:19 +0200, Stefano Lattarini wrote: >> The above has been obtained with GNU make built from latest >> git version (commit 'moved-to-git-46-g19a69ba'). > > Yes. I know the email lately has been d

Re: Some serious issues with the new -O option

On 04/30/2013 01:22 PM, Tim Murphy wrote: > I know this isn't going to go down all that well, but I really think the > output should be annotated in such a way that colourisation could be > applied to the log file after a build has already finished. > While this might (underline "might" ;-) be an i

Re: Some serious issues with the new -O option

On 04/30/2013 12:01 PM, Tim Murphy wrote: > What I mean is that: > > ./make -Otarget > > might be a good interactive default rather than -Omake. > I wasn't even aware of those differences; as of latest Git commit 'moved-to-git-46-g19a69ba', I don't see them documented in either the help screen, t

Re: Some serious issues with the new -O option

so turning that off might make things more interactive, > Per-target syncing is a valid compromise. > Indeed. > Regards, > > Tim I leave my original message quoted here in tis entirety, for reference: > > On 30 April 2013 10:48, Stefano Lattarini wrote: > >> I'm sorry

Some serious issues with the new -O option

I'm sorry to say that the new -O option can interact *badly* with Automake-generated parallel testsuites (at least when they are being run "interactively", that is, with the output of make connected to a tty). Let me elaborate a little (if you still have doubts or objections after reading the cons

Duplicated "Entering/Leaving directory" when new option -O is used

Here is a minimal reproducer: $ cd /tmp $ mkdir x $ cd x $ mkdir src $ echo 'all:; $(MAKE) -C src $@' > Makefile $ echo 'all:; @echo src' > src/Makefile $ make # Work es expected make -C src all make[1]: Entering directory '/tmp/x/src' src make[1]: Leaving directory '/tmp/x/s

Re: Default output-sync setting

On 04/29/2013 04:53 AM, Eli Zaretskii wrote: >> From: Paul Smith >> Cc: bug-make@gnu.org >> Date: Sun, 28 Apr 2013 22:03:39 -0400 >> >> Now that we seem to have a workable solution for output synchronization >> for both POSIX and Windows systems, I wonder if we shouldn't consider >> enabling it as

[PATCH] Reflect the 'configure.in' -> 'configure.ac' rename throughout

In README, code comments, and auxiliary files. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini --- ChangeLog | 9 + Makefile.DOS.template | 2 +- README.git| 4 ++-- build_w32.bat | 2 +- config.h-vms.template | 2 +- getloadavg.c

Re: Building Make out of Git: Gettext requirements

On 04/20/2013 07:00 PM, Eli Zaretskii wrote: >> Date: Sat, 20 Apr 2013 17:56:45 +0200 >> From: Stefano Lattarini >> CC: Eli Zaretskii , bug-make@gnu.org >> >> On 04/20/2013 05:44 PM, Paul Smith wrote: >>> On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii w

Re: Building Make out of Git: Gettext requirements

On 04/20/2013 05:44 PM, Paul Smith wrote: > On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote: >> Do we really need to require 0.18.1 or can this restriction be lifted? >> I hacked configure.ac to require 0.17, and didn't see any problems >> afterwards. > > You can see this bug: > > http://s

Re: NLS-related failure when building make from CVS

On 01/06/2013 07:58 PM, Paul Smith wrote: > On Sun, 2013-01-06 at 19:04 +0100, Stefano Lattarini wrote: >> Here is the error: >> >> make[2]: Entering directory `/devel/bleeding/src/make/po' >> make[2]: `be.gmo' is up to date. >> make[3]: Ente

NLS-related failure when building make from CVS

Here is the error: make[2]: Entering directory `/devel/bleeding/src/make/po' make[2]: `be.gmo' is up to date. make[3]: Entering directory `/devel/bleeding/src/make/po' File cs.po does not exist. If you are a translator, you can create it through 'msginit'. make[3]: *** [cs.po-create] Er

Cannot build the GNU make manual with development version of Texinfo

Due to this error: make.texi:8890: @itemx must follow @item If that is fixed (see diff below), the manual is build successfully. Regards, Stefano Index: doc/make.texi === RCS file: /sources/make/make/doc/make.texi,v retrieving

Re: Feature request: silently overriding existing rules

On 08/11/2012 11:49 AM, Tim Murphy wrote: > For the sake of understanding you properly, if you can detect, remove and > add targets then 'replacing the recipe silently' is just these three > operations in sequence, right? > No. A target might be defined, but might have or not have an associated re

Re: Feature request: silently overriding existing rules

On 08/11/2012 07:36 AM, Tim Murphy wrote: > This is a different thing but I'd have had great use for a way to tell if a > target had been defined previously. Had to use variables to do it which > used a lot of memory and it was a total waste because make has the > information already. > I dimly rem

Re: Feature request: silently overriding existing rules

On 08/11/2012 01:27 AM, David Boyce wrote: > On Fri, Aug 10, 2012 at 2:38 PM, Stefano Lattarini > wrote: >> I have no answer for that, lacking any knowledge about GNU make >> internals; I guess the make developers here will be in a better >> position to answer my questi

Re: Feature request: silently overriding existing rules

Hi David, thanks for the feedback. On 08/10/2012 07:00 PM, David Boyce wrote: > Even with GNU make as it stands, couldn't you emit your rules in the > form of variables, override them at will, and eval() them at the end? > E.g. > > define ruleA > version 1 > endef > > then later... > > define r

Feature request: silently overriding existing rules

In some situations, it would be very useful to be able to override already-defined rules for a target without having GNU make complaining about the override. For example, when writing a "library" of makefiles recipes, organized as a set of makefile fragments to be included by a "master" (user-writ

GNU make strips leading whitespace from variables defined from the command line

Make version: GNU Make 3.82 Built for i686-pc-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the exten

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

On 07/19/2012 08:03 AM, John Joganic wrote: > Follow-up Comment #2, bug #36881 (project make): > > Thank you for the information. > > I must say that I'm rather concerned that fundamental syntax has changed with > no mention in the manual. > AFAIU, the manual, being a reference manual, is just a

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

On 06/12/2012 02:06 AM, Philip Guenther wrote: > On Mon, Jun 11, 2012 at 12:53 PM, Stefano Lattarini > wrote: > ... >> I was hoping to be able to the order-only prerequisites to enforce ordering >> between .PHONY targets. At this point, I guess I should state the problem &g

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

Hi Paul, thanks for the quick answer. On 06/12/2012 07:14 AM, Paul Smith wrote: > On Mon, 2012-06-11 at 18:40 +0200, Stefano Lattarini wrote: >> The GNU make 3.82 manual reads: >> >> Normally, this is exactly what you want: if a target's prerequisite >> is

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

On 06/11/2012 07:03 PM, Philip Guenther wrote: > On Mon, Jun 11, 2012 at 9:40 AM, Stefano Lattarini > wrote: >> The GNU make 3.82 manual reads: >> >>Normally, this is exactly what you want: if a target's prerequisite >>is updated, the

order-only prerequisites don't behave as I'd have expected after reading the documentation

The GNU make 3.82 manual reads: Normally, this is exactly what you want: if a target's prerequisite is updated, then the target should also be updated. Occasionally, however, you have a situation where you want to impose a specific ordering on the rules to be invoked without forci

Re: Unexpected failure in tricky use of eval

On 05/14/2012 05:10 PM, Paul Smith wrote: > On Mon, 2012-05-14 at 00:14 +0200, Stefano Lattarini wrote: > >>>> LAZYVAR = $(override LAZYVAR := val)$(LAZY) >>> >>> I don't have any idea what this is supposed to do... it doesn't make any >>>

Re: Unexpected failure in tricky use of eval

On 05/13/2012 09:45 PM, Paul Smith wrote: > On Sat, 2012-05-12 at 19:42 +0200, Stefano Lattarini wrote: >> BTW: to make it more easy to discover at make runtime whether the bug has >> been fixed in the make version in use, could a proper new entry be added >> to .FEATURES?

"Lazy" variables in GNU make (was: Re: Unexpected failure in tricky use of eval)

On 05/12/2012 07:42 PM, Stefano Lattarini wrote: > On 05/12/2012 05:21 PM, Stefano Lattarini wrote: >> On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: >>> Stefano, >>> >>> This is a bug, and it has been described and fixed here: >>> https://savannah.g

Re: Unexpected failure in tricky use of eval

On 05/12/2012 05:21 PM, Stefano Lattarini wrote: > On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: >> Stefano, >> >> This is a bug, and it has been described and fixed here: >> https://savannah.gnu.org/patch/?7534 >> > Thank you very much for the reference. Too

Re: Unexpected failure in tricky use of eval

On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: > Stefano, > > This is a bug, and it has been described and fixed here: > https://savannah.gnu.org/patch/?7534 > Thank you very much for the reference. Too bad this bug will prevent me from using the lazy-evaluation trick with any GNU make < 3.83 :

Unexpected failure in tricky use of eval

Hello. While trying to implement a kind of memoization of lazy macros in GNU make (needed for my work on Automake-NG), I've been encountering some strange failure in GNU make (present in all of 3.80, 3.81, 3.82). Here is the minimal reproducer I've been able to find: mufoofoo = \ x

Re: Cleanup of makefiles 'n stuff

On 01/17/2012 09:04 PM, Sebastian Pipping wrote: > > Git please. It's fast, used by important GNU projects [1] ... [SNIP] > > [1] http://git.savannah.gnu.org/cgit/coreutils.git > And FTR also: http://git.savannah.gnu.org/cgit/libtool.git http://git.savannah.gnu.org/cgit/autoconf.git http:/

Re: patch to support output synchronization under -j

On Tuesday 03 May 2011, Paul Smith wrote: > On Tue, 2011-05-03 at 09:48 +0200, Stefano Lattarini wrote: > > > The other thing I was thinking is that this feature might want to be > > > enabled via a command-line argument. All the complex makefiles > > > generated

Re: patch to support output synchronization under -j

Hello Paul. Just my 2 cents regarding Automake ... On Tuesday 03 May 2011, Paul Smith wrote: > > The other thing I was thinking is that this feature might want to be > enabled via a command-line argument. All the complex makefiles > generated by automake, etc. for example cannot take advantage o

Re: patch to support output synchronization under -j

Hello everybody. On Friday 15 April 2011, Eli Zaretskii wrote: > Btw, there will be other side effects, at least on non-Posix > platforms, due to the fact that stuff that was supposed to go to the > screen is redirected to a file instead. Some programs sense that and > behave differently, e.g. wi

VPATH and filenames with double-slash `//'

Hello everybody. I think I've found a bug in GNU make, apparently due to the interaction of VPATH and filenames with double-slash `//'. Here is an excerpt showing the most relevant part of the bug: $ cat Makefile VPATH = .. foo_OBJECTS = ./src//foo.o foo: $(foo_OBJECTS) $(CC) -o