[PATCH] build: Automake fixes (in particular re-enabling 'gnu' strictness)
And make the package bootstrap again with Automake = 1.14, and require Automake = 1.12 (see below for a rationale). * Makefile.am: Add a dummy 'ChangeLog' target, so that Automake in 'gnu' strictness won't complain about a missing ChangeLog file; that file has recently switched to be autogenerated by recipes in 'maintMakefile'. (AUTOMAKE_OPTIONS): Delete redundant version requirement for 1.8 or later. Move options that only make sense for the top-level dir ... * configure.ac (AM_INIT_AUTOMAKE): ... in here. Bump requirement to Automake 1.12 (see below for a rationale). Drop the 'foreign' option, thus going back to the default 'gnu' strictness. Drop the '-Werror' option as well, so that the warning that Automake 1.14 gives about the 'subdir-objects' option not being enable will not be fatal (which is appropriate: any Automake in the 1.x series is required to still produce correct Makefiles even when the 'subdir-object' option is disabled. Also, while at it ... (AC_CHECK_PROG): ... drop the check for 'ar' here, and instead use AM_PROG_AR: this also avoids a Windows-related portability 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 strictly required, but better play safe). Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Makefile.am | 1 - configure.ac | 7 +++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/Makefile.am b/Makefile.am index e2c0fe9..d820d33 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,7 +16,6 @@ # You should have received a copy of the GNU General Public License along with # this program. If not, see http://www.gnu.org/licenses/. -AUTOMAKE_OPTIONS = 1.8 dist-bzip2 check-news ACLOCAL_AMFLAGS= -I config MAKE_HOST =@MAKE_HOST@ diff --git a/configure.ac b/configure.ac index 8e11328..030adf5 100644 --- a/configure.ac +++ b/configure.ac @@ -26,15 +26,15 @@ AC_CONFIG_SRCDIR([vpath.c]) AC_CONFIG_HEADERS([config.h]) # Automake setup -# We have to enable foreign because ChangeLog is auto-generated -AM_INIT_AUTOMAKE([1.11.1 silent-rules foreign -Wall -Werror]) +AM_INIT_AUTOMAKE([1.12 silent-rules dist-bzip2 check-news -Wall]) # Checks for programs. AC_PROG_CC +AM_PROG_CC_C_O AC_PROG_INSTALL AC_PROG_RANLIB AC_PROG_CPP -AC_CHECK_PROG([AR], [ar], [ar], [ar]) +AM_PROG_AR # Perl is needed for the test suite (only) AC_CHECK_PROG([PERL], [perl], [perl], [perl]) @@ -65,7 +65,6 @@ AC_HEADER_TIME AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h string.h \ memory.h sys/param.h sys/resource.h sys/time.h sys/timeb.h]) -AM_PROG_CC_C_O AC_C_CONST AC_TYPE_SIGNAL AC_TYPE_UID_T -- 1.8.3.1.605.g85318f5 ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[PATCH v2] build: Automake fixes (in particular re-enabling 'gnu' strictness)
And make the package bootstrap again with Automake = 1.14, and require Automake = 1.12 (see below for a rationale). * Makefile.am: Add a dummy 'ChangeLog' target, so that Automake in 'gnu' strictness won't complain about a missing ChangeLog file; that file has recently switched to be autogenerated by recipes in 'maintMakefile'. (AUTOMAKE_OPTIONS): Delete redundant version requirement for 1.8 or later. Move options that only make sense for the top-level dir ... * configure.ac (AM_INIT_AUTOMAKE): ... in here. Bump requirement to Automake 1.12 (see below for a rationale). Drop the 'foreign' option, thus going back to the default 'gnu' strictness. Drop the '-Werror' option as well, so that the warning that Automake 1.14 gives about the 'subdir-objects' option not being enable will not be fatal (which is appropriate: any Automake in the 1.x series is required to still produce correct Makefiles even when the 'subdir-object' option is disabled. Also, while at it ... (AC_CHECK_PROG): ... drop the check for 'ar' here, and instead use AM_PROG_AR: this also avoids a Windows-related portability 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 strictly required, 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 stefano.lattar...@gmail.com --- Sorry, the previous patch I sent was borked, ignore it. This one is the real deal. Thanks, Stefano .gitignore| 3 +- INSTALL | 231 -- Makefile.am | 8 +- config/.gitignore | 1 + configure.ac | 7 +- 5 files changed, 10 insertions(+), 240 deletions(-) delete mode 100644 INSTALL diff --git a/.gitignore b/.gitignore index 6e3f5a2..d7f00a6 100644 --- a/.gitignore +++ b/.gitignore @@ -7,8 +7,9 @@ TAGS #* .#* -# Configure artifacts +# Autotools and configure artifacts ABOUT-NLS +INSTALL Makefile Makefile.in aclocal.m4 diff --git a/INSTALL b/INSTALL deleted file mode 100644 index 095b1eb..000 --- a/INSTALL +++ /dev/null @@ -1,231 +0,0 @@ -Installation Instructions -* - -Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004 Free -Software Foundation, Inc. - -This file is free documentation; the Free Software Foundation gives -unlimited permission to copy, distribute and modify it. - -Basic Installation -== - -These are generic installation instructions. - - The `configure' shell script attempts to guess correct values for -various system-dependent variables used during compilation. It uses -those values to create a `Makefile' in each directory of the package. -It may also create one or more `.h' files containing system-dependent -definitions. Finally, it creates a shell script `config.status' that -you can run in the future to recreate the current configuration, and a -file `config.log' containing compiler output (useful mainly for -debugging `configure'). - - It can also use an optional file (typically called `config.cache' -and enabled with `--cache-file=config.cache' or simply `-C') that saves -the results of its tests to speed up reconfiguring. (Caching is -disabled by default to prevent problems with accidental use of stale -cache files.) - - If you need to do unusual things to compile the package, please try -to figure out how `configure' could check whether to do them, and mail -diffs or instructions to the address given in the `README' so they can -be considered for the next release. If you are using the cache, and at -some point `config.cache' contains results you don't want to keep, you -may remove or edit it. - - The file `configure.ac' (or `configure.in') is used to create -`configure' by a program called `autoconf'. You only need -`configure.ac' if you want to change it or regenerate `configure' using -a newer version of `autoconf'. - -The simplest way to compile this package is: - - 1. `cd' to the directory containing the package's source code and type - `./configure' to configure the package for your system. If you're - using `csh' on an old version of System V, you might need to type - `sh ./configure' instead to prevent `csh' from trying to execute - `configure' itself. - - Running `configure' takes awhile. While running, it prints some - messages telling which features it is checking for. - - 2. Type `make' to compile the package. - - 3. Optionally, type `make check' to run any self-tests that come with - the package. - - 4. Type `make install' to install the programs and any data files and - documentation. - - 5. You can remove the program
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 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 (I behavior I actively dislike, since it cannot be worked around). And it also has several other terrible hacks and quirks. For more info, see: http://www.gnu.org/software/autoconf/manual/autoconf.html#Parallel-Make Nevertheless, I do wonder whether forcing stdout/stderr into O_APPEND mode would be worthwhile. It would fix this problem in any event. I'm having a hard time coming up with a reason NOT to do it. To be clear: I'm not opposing to the change in any way; it's just that I don't feel comfortable enough with the area to give an explicit ACK. If you think the change would be worthwhile, go for it :-) I trust your judgment far more than mine. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 thing? I'll have to look into it; maybe there's a good reason for doing it this way. FWIW, the current behavior of $(MFLAGS) and $(MAKEFLAGS) is used as a feature in Automake-NG (my Automake fork that assumes the generated makefiles will only be run by GNU make); see the comments about the 'am.make.is-running-with-option' macro in http://git.sv.gnu.org/cgit/automake.git/tree/lib/am/header-vars.mk?h=ng/master Changing it will probably break something there :-( But maybe, are you willing to implement new macro(s) that makes is easier to probe at runtime, from within the makefiles, the flags passed to GNU make? In that case, I'd be more than willing to adjust Automake and/or Automake-NG to take advantage of that. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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. * Extraneous enter/leave lines are not printed any longer. I still see them actually, if I try to build the latest coreutils from git with: $ make -j8 -O Can you reproduce? If yes, I'll leave the matter in your hands. * I renamed the options to -Oline, -Otarget (not changed) and -Orecurse. * I took another stab at documentation; please check the Parallel Output node and see if it is more understandable now. Some picky details of -Otarget I didn't spell out but hopefully it's more clear. Please test the heck out of this with the different modes in your most difficult build environments, and let me know if you see any anomalies. I'm also interested to know if the enter/leave stuff is really correct now; Not for me. it is in my testing but it sort of happened more by accident than real planning. We are right on the cusp of a release candidate for the next GNU make version. If you have the ability to build and test from Git feel free to start your testing early. Thanks, and sorry not to be more helpful, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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/make/tests/../make \ (expected 0; got 14): /storage/home/stefano/src/gnu/make/tests/../make \ -f work/features/output-sync.mk.1 -j --output-sync=target Caught signal 14! FAILED (4/6 passed) Can you reproduce the failure? If not, let me know which information you need to debug this, and I'll try to provide them. It didn't fail for me. However, it's possible that the 6 second timeout is just a little too short for reliability. 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 even in that case, the failure is racy. With a bare make check, things work for me as well. On the other hand, increasing the parallelism even more, other tests start to fail as well: -*-*-*- $ make check -j16 Making check in glob make[1]: Entering directory `/storage/home/stefano/src/gnu/make/glob' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/storage/home/stefano/src/gnu/make/glob' Making check in config make[1]: Entering directory `/storage/home/stefano/src/gnu/make/config' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/storage/home/stefano/src/gnu/make/config' Making check in po make[1]: Entering directory `/storage/home/stefano/src/gnu/make/po' make[1]: Leaving directory `/storage/home/stefano/src/gnu/make/po' Making check in doc make[1]: Entering directory `/storage/home/stefano/src/gnu/make/doc' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/storage/home/stefano/src/gnu/make/doc' make[1]: Entering directory `/storage/home/stefano/src/gnu/make' make loadavg make[2]: Entering directory `/storage/home/stefano/src/gnu/make' make[2]: Leaving directory `/storage/home/stefano/src/gnu/make' make check-local make[2]: Entering directory `/storage/home/stefano/src/gnu/make' cd tests perl ./run_make_tests.pl -srcdir /storage/home/stefano/src/gnu/make -make ../make The system uptime program believes the load average to be: uptime 11:01:21 up 47 min, 4 users, load average: 0.03, 0.19, 0.21 The GNU load average checking code thinks: ./loadavg 1-minute: 0.03 5-minute: 0.19 15-minute: 0.21 -- Running tests for GNU make on Linux laptop 3.2.0-4-amd64 x86_64 GNU Make 3.82.90 -- Clearing work... Finding tests... features/archives ... ok (8 passed) features/comments ... ok (1 passed) features/conditionals ... ok (4 passed) features/default_names .. ok (3 passed) features/double_colon ... *** Test died (features/double_colon): test_driver.pl: 468 - scripts/features/double_colon: 77: Couldn't touch foo: Is a directory FAILED (4/4 passed) features/echoing ok (4 passed) features/errors . *** Test died (features/errors): test_driver.pl: 468 - scripts/features/errors: 41: Couldn't touch foo: Is a directory FAILED (0/0 passed) features/escape . FAILED (7/8 passed) features/export . ok (12 passed) features/include Error running /storage/home/stefano/src/gnu/make/tests/../make (expected 0; got 512): /storage/home/stefano/src/gnu/make/tests/../make -f work/features/include.mk.4 Error running /storage/home/stefano/src/gnu/make/tests/../make (expected 0; got 512): /storage/home/stefano/src/gnu/make/tests/../make -f work/features/include.mk.5 FAILED (5/10 passed) features/load ... ok (6 passed) features/loadapi ok (3 passed) features/mult_rules . ok (2 passed) features/mult_targets ... ok (2 passed) features/order_only . FAILED (6/10 passed) features/output-sync ok (6 passed) features/override ... ok (4 passed) features/parallelism ok (10 passed) features/patspecific_vars ... ok (10 passed) features/patternrules ... ok (10 passed) features/quoting ok (1 passed) features/recursion
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 even in that case, the failure is racy. With a bare make check, things work for me as well. On the other hand, increasing the parallelism even more, other tests start to fail as well: The test suite definitely cannot be run in parallel. I realize that (and it's no issue, considering how fast the make testsuite is); but I often run a make -j8 check just after running ./configure (requires less typing than make -j8 make check), and that's where things broke down. However this should not happen (and does not happen in my environment when I run the commands above) because the test harness cleans out the environment, which will remove any of the MAKEFLAGS or MFLAGS variables that might tell the make to run in parallel when it's not expected. Can you examine your shell configuration files etc. to see if they're setting MAKEFLAGS or MFLAGS? Definitely not. Although if that's true then the tests should fail all the time. Can you verify that there don't seem to be any leftover test files in the tests directory? Sometimes if something doesn't get cleaned up correctly that can cause future builds to fail. However if that were the case then make check without -j would fail as well. I don't have an explanation for this. It's no big deal; I can just run make check and live happily. Also, I don't have the mental bandwidth to try to debug this ATM, sorry. Let's return to the issue if I get bitten again. Or maybe you'll manage to reproduce the issue somehow. In the meantime, thanks for your help and your attention, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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. * glob/glob.h: Likewise. * job.c: Likewise. * main.c: Likewise. * readme.vms: Likewise. * remake.c: Likewise. * tests/ChangeLog: Likewise. * tests/NEWS: Likewise. * tests/README: Likewise. * tests/scripts/variables/private: Likewise. * vmsdir.h: Likewise. * signame.c: Likewise. While at it, improve line wrapping in the touched comment. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com Ping? Any reason not to apply this trivial patch? Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 :-). Many of these kinds of things have to wait until the weekends. OK, no problem. I just wanted to ensure this didn't fall through the cracks. I will be more patient next time. It's queued and I'll get to it, thanks! Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 normal synchronized output function). I've implemented this feature and it seems to work as expected. I also implemented the fix to the duplicate output being shown in some cases. I have two open issues I want to address before calling this feature done: first, fix make's writing of the command it's going to run (for rules that don't start with @) as that's not working right. Second, fix the enter/leave issue. It turns out that these are currently somewhat bound together so I may have to solve the second one first. The test 'features/output-sync' now fails for me: Test timed out after 6 seconds Error running /storage/home/stefano/src/gnu/make/tests/../make \ (expected 0; got 14): /storage/home/stefano/src/gnu/make/tests/../make \ -f work/features/output-sync.mk.1 -j --output-sync=target Caught signal 14! FAILED (4/6 passed) Can you reproduce the failure? If not, let me know which information you need to debug this, and I'll try to provide them. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 stefano.lattar...@gmail.com
---
doc/make.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/make.texi b/doc/make.texi
index ea58d6e..fa9b5d7 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -8812,7 +8812,7 @@ from complicated nests of recursive @code{make} commands.
rarely need to specify this option since @samp{make} does it for you;
see @ref{-w Option, ,The @samp{--print-directory} Option}.)
-@itemx --no-print-directory
+@item --no-print-directory
@cindex @code{--no-print-directory}
Disable printing of the working directory under @code{-w}.
This option is useful when @code{-w} is turned on automatically,
--
1.8.3.rc0.19.g7e6a0cc
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
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 that the testsuite runs as one long operation, updating one target, and the recipe invokes one test script, right? No; the testsuite runs as a recursive make invocation (yes, this is sadly truly needed in order to support all the features offered by the Automake parallel testsuite harness --- sorry), but each test script (and there can be hundreds of them, as is the case for GNU coreutils or GNU automake itself) is run as a separate target, explicit for tests which have no extension and pattern-based for tests that have an extension. This should work very well with -Otarget then, except for the colorization/highlighting issue... once it works as expected. I'll look into this issue later and I would be interested to see your experience with it once it's resolved. OK, I found this bug. Definitely make recursion was not being handled properly with -Otarget and -Ojob in some situations; this broke as a side effect of my cleanup to reuse the same temporary file for the entire target, regardless of the output mode. This should be fixed now. Those who use recursive makefiles and were seeing annoying delays in output with -O, please try again with the latest commit and see if it works any better for you now. I can confirm the problem has disappeared for me. Thanks! (The issue with extra Entering/Leaving directory messages is still present though; I hope it can be fixed before the release ...). Best regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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/src' $ make -O # Duplicated lines in output make -C src all make[1]: Entering directory '/tmp/x/src' make[1]: Entering directory '/tmp/x/src' src make[1]: Leaving directory '/tmp/x/src' make[1]: Leaving directory '/tmp/x/src' The above has been obtained with GNU make built from latest git version (commit 'moved-to-git-46-g19a69ba'). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 considerations below, please do not hesitate to ask for clarifications). For long-running testsuite with lots of tests, the use of the '-O' option prevents the results from the tests already run to be displayed on the screen until the *whole* testsuite has run. IMO, this destroys feedback and readability of the output. Try building GNU coreutils and running its testsuite with make -j2 -O on a slowish system to see how this can be annoying in practice. Moreover, since the output of the recipes is no longer connected to a terminal, automatic colorization of output no longer work: no more good results in green and failures in red (unless the user forces them by exporting AM_COLOR_TESTS to always). In defense of the '-O' option, I must say that I see how such an option can be actually useful to produce more readable logs when the output is being redirected to a file (so that one doesn't care about real-time feedback on the console); but for most interactive usages, I believe its downsides definitely overweight its advantages. So please don't ever make that option the default; if you really really want to, at least put in place some smart checks that only enable '-O' when the output is *not* a tty, so that we can have the best of both worlds (useful feedback for interactive runs, more readable logs for batch runs). Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Some serious issues with the new -O option
On 04/30/2013 11:55 AM, Tim Murphy wrote: I'm guessing here but I imagine the main problem comes with delaying the results of submakes? I think so, yes. The Distributed Make from Sun implements a similar output synchronization feature, and doesn't have the output delay problems I have experienced with GNU make (while it shares the issues with automatic output colorization). I haven't tested to see if this is how the new feature works or not. I don't think it's completely necessary to keep all output from one submake together. 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 stefano.lattar...@gmail.comwrote: 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 considerations below, please do not hesitate to ask for clarifications). For long-running testsuite with lots of tests, the use of the '-O' option prevents the results from the tests already run to be displayed on the screen until the *whole* testsuite has run. IMO, this destroys feedback and readability of the output. Try building GNU coreutils and running its testsuite with make -j2 -O on a slowish system to see how this can be annoying in practice. Moreover, since the output of the recipes is no longer connected to a terminal, automatic colorization of output no longer work: no more good results in green and failures in red (unless the user forces them by exporting AM_COLOR_TESTS to always). In defense of the '-O' option, I must say that I see how such an option can be actually useful to produce more readable logs when the output is being redirected to a file (so that one doesn't care about real-time feedback on the console); but for most interactive usages, I believe its downsides definitely overweight its advantages. So please don't ever make that option the default; if you really really want to, at least put in place some smart checks that only enable '-O' when the output is *not* a tty, so that we can have the best of both worlds (useful feedback for interactive runs, more readable logs for batch runs). Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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, the manpage, the texinfo manual, nor the NEWS file. Colouring is another issue which I would imagine could be done another way to let us have the best of both worlds. That is not trivial to do I think. For example, Automake-generated testsuites check whether the stdout is a tty to decide whether or not to automatically enable output colorization. And testsuites produced by Autotest do the same, AFAIK. If the make connects the stdout of those processes to non-tty files behind the scene, those checks are doomed to fail. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 interesting feature, it is orthogonal to the issue under question -- that is, the need to retain the ability to automatically determine whether the output is going to a tty or a log file (that is, any file that is not a tty). e..g you load a makefile into VIM - it can colourise it. Or a bit of C source code. Why not the log of a build you did yesteday? It's still very nice to be able to distinguish things by colour later on. And notice that, currently, such a post-run colorization is easy to obtain, if you are only interested in having it working 99% of the time: just color a leading PASS: string in green, a leading FAIL: in red, e leading SKIP: in blue, etc. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 daunting but if you wade through it you'll see a number of emails discussing this issue; it definitely needs to be addressed before release. Sorry, I didn't follow most of the e-mail discussions (and I failed to properly search the archives, oops). Anyway, good to know this is on your radar. Thanks for testing Stefano! Thanks, and best regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[PATCH] 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. * TODO.private: Likewise. * function.c: Likewise. * glob/glob.h: Likewise. * job.c: Likewise. * main.c: Likewise. * readme.vms: Likewise. * remake.c: Likewise. * tests/ChangeLog: Likewise. * tests/NEWS: Likewise. * tests/README: Likewise. * tests/scripts/variables/private: Likewise. * vmsdir.h: Likewise. * signame.c: Likewise. While at it, improve line wrapping in the touched comment. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- ChangeLog | 24 ChangeLog.2 | 2 +- README.Amiga| 12 ++-- TODO.private| 2 +- function.c | 2 +- glob/glob.h | 2 +- job.c | 2 +- main.c | 4 ++-- readme.vms | 2 +- remake.c| 2 +- signame.c | 8 tests/ChangeLog | 10 +- tests/NEWS | 2 +- tests/README| 4 ++-- tests/scripts/variables/private | 2 +- vmsdir.h| 2 +- 16 files changed, 53 insertions(+), 29 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6badda8..3ad0050 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,27 @@ +2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (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. + * TODO.private: Likewise. + * function.c: Likewise. + * glob/glob.h: Likewise. + * job.c: Likewise. + * main.c: Likewise. + * readme.vms: Likewise. + * remake.c: Likewise. + * tests/ChangeLog: Likewise. + * tests/NEWS: Likewise. + * tests/README: Likewise. + * tests/scripts/variables/private: Likewise. + * vmsdir.h: Likewise. + * signame.c: Likewise. While at it, improve line wrapping in the + touched comment. + 2013-04-29 Eli Zaretskii e...@gnu.org * w32/include/dlfcn.h: New file. diff --git a/ChangeLog.2 b/ChangeLog.2 index 1705b76..0816454 100644 --- a/ChangeLog.2 +++ b/ChangeLog.2 @@ -3080,7 +3080,7 @@ Sun May 12 19:19:43 1996 Aaron Digulla digu...@fh-konstanz.de * main.c: (main), variable.c Changed handling of ENV-vars. Make stores now the names of the variables only and reads their contents when they are accessed to reflect that these variables are really - global (ie. they CAN change WHILE make runs !) This handling is + global (i.e., they CAN change WHILE make runs !) This handling is made in lookup_variable() * Makefile.ami: renamed file.h to filedep.h diff --git a/README.Amiga b/README.Amiga index aa82251..fa18814 100644 --- a/README.Amiga +++ b/README.Amiga @@ -25,8 +25,8 @@ GNU make): endif @@\ $(CC) Link Make.o To make -works. Note that the @@ must stand alone (ie. make@@\ is illegal). -Also be carefull that there is a space after the \ (ie, at the +works. Note that the @@ must stand alone (i.e., make@@\ is illegal). +Also be careful that there is a space after the \ (i.e., at the beginning of the next line). - Can be made resident to save space and time - Amiga specific wildcards can be used in $(wildcard ...) @@ -36,17 +36,17 @@ BUGS: dummy.h : src/*.c -tries to make dummy.h from src/*.c (ie. no wildcard-expansion takes +tries to make dummy.h from src/*.c (i.e., no wildcard-expansion takes place). You have to use $(wildcard src/*.c) instead. COMPILING FROM SCRATCH -- -To recompile, you need SAS/C 6.51. make itself is not neccessary, there +To recompile, you need SAS/C 6.51. make itself is not necessary, there is an smakefile. 1. Copy config.ami to config.h -2. If you use make to compie, copy Makefile.ami to Makefile and +2. If you use make to compile, copy Makefile.ami to Makefile and glob/Makefile.ami to glob/Makefile. Copy make into the current directory. @@ -54,7 +54,7 @@ is an smakefile. INSTALLATION -Copy make somewhere in your search path (eg. sc:c or sc:bin). +Copy make somewhere in your search path (e.g., sc:c or sc:bin). If you plan to use recursive makes, install make resident: Resident make Add diff --git a/TODO.private b/TODO.private index c3dda97..abb7410 100644 --- a/TODO.private +++ b/TODO.private @@ -6,7 +6,7 @@ This list comes both from the authors and from users of GNU make. They are listed in no particular order! -Also, I don't gaurantee that all of them will be ultimately deemed good +Also, I don't guarantee that all of them
Re: Some serious issues with the new -O option
Hi Paul. On 04/30/2013 03:37 PM, Paul Smith wrote: Just to be clear, you're saying that the testsuite runs as one long operation, updating one target, and the recipe invokes one test script, right? No; the testsuite runs as a recursive make invocation (yes, this is sadly truly needed in order to support all the features offered by the Automake parallel testsuite harness --- sorry), but each test script (and there can be hundreds of them, as is the case for GNU coreutils or GNU automake itself) is run as a separate target, explicit for tests which have no extension and pattern-based for tests that have an extension. I can see how that environment might be problematic for this new feature. It works much better for lots of smaller targets. See above: we are speaking of hundreds of little targets here ... However, you could avoid this issue if you specify that the target to be built is a sub-make, The problem here is exactly the fact that the output of the sub-make is not displayed until its execution has ended. by prefixing it with a + operator for example. BTW, the + operator is not portable soem other make implementations still targeted by Automake (e.g., Solaris make). If this is true and you use -Otarget or -Ojob then make will not capture the output from that job. Of course this also has the unfortunate side-effect that running make -n 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 checks that only enable '-O' when the output is *not* a tty, so that we can have the best of both worlds (useful feedback for interactive runs, more readable logs for batch runs). This is a possibility for sure. I have to say that my experience with parallel builds hasn't been as wonderful as others here. OTOH, mine has been very good, and I almost alway use make -j8 or higher when building GNU software (or other good software the relies on GNU make, like Git). The only real issues I've experienced so far have been when I used the '-O' option ... I often get output which is corrupted, and not just by intermixing whole lines but also by having individual lines intermixed (that is the beginning of the line is one job's output, then the end of the line is another job's output, etc.) Most of these issues are solved using silent-rules, as offered by Automake or implemented ad-hoc by build systems of other software (Git, Linux). I think the best ways to use parallel GNU make are: - with silent rules when the output goes to a tty (it makes the output visually scannable, and makes warnings and error messages form compilers and most other tools stand out much more clearly). - with verbose rules and possibly the -O option enabled when the output goes to a log, to simplify post-build debugging and analysis (especially useful with CI systems and the like). This kind of corruption is often completely unrecoverable and I simply re-run the build without parallelism enabled. I think it depends on how much output jobs emit and how many you are running at the same time. Indeed; this corresponds to my experiences so far. It could also be that Windows is better about avoiding interrupted writes to the same device. Not using windows, I cannot say anything here, sorry. Tim Murphy tnmur...@gmail.com writes: What I mean is that: ./make -Otarget might be a good interactive default rather than -Omake. I always intended that and never suggested -Omake would be the default. I think -Omake is only really useful for completely automated, background builds. It wouldn't ever be something someone would use if they wanted to watch the build interactively. I haven't tested to see if this is how the new feature works or not. I don't think it's completely necessary to keep all output from one submake together. so turning that off might make things more interactive, Per-target syncing is a valid compromise. This is the default. If you use -Otarget or (-Ojob) then what is supposed to happen is that make uses the same sub-make detection algorithms used for jobserver, etc. and if it determines that a job it's going to run is a submake it does NOT collect its output. This appears not to be the case, actually ... However, I have suspicions that this is not working properly. I have a make-based cross-compilation environment (building gcc + tools) I've been using for years, and I tried it with the latest make and -O and saw similar problems (sub-make output collected into one large log instead of per-target). Glad to know you can reproduce this. Thinking about it right now I think I might know what the problem is, actually. I'll look at this later. Thanks! Stefano Lattarini stefano.lattar...@gmail.com writes: I wasn't even aware of those
[PATCH 1/3] build: require Autoconf = 2.62 and Automake = 1.11.1
Older versions of those tools should be considered fully obsolete. Also, GNU make already requires Gettext = 0.18.1, which has been released six months after Automake 1.11.1 and two years after Autoconf 2.62; so the new requirement shouldn't be problematic for people already bootstrapping 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 stefano.lattar...@gmail.com --- ChangeLog| 14 ++ configure.ac | 6 +++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6badda8..5278d49 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + + build: require Autoconf = 2.62 and Automake = 1.11.1 + + Older versions of those tools should be considered fully obsolete. + Also, GNU make already requires Gettext = 0.18.1, which has been + released six months after Automake 1.11.1 and two years after + Autoconf 2.62; so the new requirement shouldn't be problematic + for people already bootstrapping 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). + 2013-04-29 Eli Zaretskii e...@gnu.org * w32/include/dlfcn.h: New file. diff --git a/configure.ac b/configure.ac index d610343..548bc42 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ # Process this file with autoconf to produce a configure script. # -# Copyright (C) 1993-2012 Free Software Foundation, Inc. +# Copyright (C) 1993-2013 Free Software Foundation, Inc. # This file is part of GNU Make. # # GNU Make is free software; you can redistribute it and/or modify it under @@ -18,7 +18,7 @@ AC_INIT([GNU make],[3.82.90],[bug-make@gnu.org]) -AC_PREREQ([2.59]) +AC_PREREQ([2.62]) # Autoconf setup AC_CONFIG_AUX_DIR([config]) @@ -26,7 +26,7 @@ AC_CONFIG_SRCDIR([vpath.c]) AC_CONFIG_HEADERS([config.h]) # Automake setup -AM_INIT_AUTOMAKE([1.9]) +AM_INIT_AUTOMAKE([1.11.1]) # Checks for programs. AC_PROG_CC -- 1.8.3.rc0.19.g7e6a0cc ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 stefano.lattar...@gmail.com --- ChangeLog| 8 configure.ac | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 5278d49..6abc7bc 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + 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. + +2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + build: require Autoconf = 2.62 and Automake = 1.11.1 Older versions of those tools should be considered fully obsolete. diff --git a/configure.ac b/configure.ac index 548bc42..c6a5482 100644 --- a/configure.ac +++ b/configure.ac @@ -26,7 +26,7 @@ AC_CONFIG_SRCDIR([vpath.c]) AC_CONFIG_HEADERS([config.h]) # Automake setup -AM_INIT_AUTOMAKE([1.11.1]) +AM_INIT_AUTOMAKE([1.11.1 subdir-objects silent-rules]) # Checks for programs. AC_PROG_CC -- 1.8.3.rc0.19.g7e6a0cc ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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' automake options build: get rid of 'HAVE_ANSI_COMPILER' C preprocessor conditional ChangeLog | 35 +++ config.ami.template | 3 --- config.h-vms.template | 3 --- config.h.W32.template | 3 --- configh.dos.template | 3 --- configure.ac | 12 +++- 6 files changed, 38 insertions(+), 21 deletions(-) -- 1.8.3.rc0.19.g7e6a0cc ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[PATCH 3/3] build: get rid of 'HAVE_ANSI_COMPILER' C preprocessor conditional
GNU make already assume C89 or later throughout the codebase, and that preprocessor conditional was no longer used anyway. * configure.ac: Remove AC_DEFINE of HAVE_ANSI_COMPILER. * config.ami.template: Remove #define of HAVE_ANSI_COMPILER. * config.h-vms.template: Likewise. * config.h.W32.template: Likewise. * configh.dos.template: Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- 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 changed, 13 insertions(+), 18 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6abc7bc..433ac5f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,18 @@ 2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + build: get rid of 'HAVE_ANSI_COMPILER' C preprocessor conditional + + GNU make already assume C89 or later throughout the codebase, and + that preprocessor conditional was no longer used anyway. + + * configure.ac: Remove AC_DEFINE of HAVE_ANSI_COMPILER. + * config.ami.template: Remove #define of HAVE_ANSI_COMPILER. + * config.h-vms.template: Likewise. + * config.h.W32.template: Likewise. + * configh.dos.template: Likewise. + +2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + build: enable 'subdir-objects' and 'silent-rules' automake options * configure.ac (AM_INIT_AUTOMAKE): Here. The future major Automake diff --git a/config.ami.template b/config.ami.template index 8fe26bd..78e2e75 100644 --- a/config.ami.template +++ b/config.ami.template @@ -157,9 +157,6 @@ this program. If not, see http://www.gnu.org/licenses/. */ /* Define if the 'S_IS*' macros in sys/stat.h do not work properly. */ /* #undef STAT_MACROS_BROKEN */ -/* Define if your compiler conforms to the ANSI C standard. */ -#define HAVE_ANSI_COMPILER 1 - /* Define if you have the ANSI C header files. */ #define STDC_HEADERS diff --git a/config.h-vms.template b/config.h-vms.template index 1b99dd4..dd1aa1e 100644 --- a/config.h-vms.template +++ b/config.h-vms.template @@ -330,9 +330,6 @@ this program. If not, see http://www.gnu.org/licenses/. */ /* Define to 1 if you have the ndir.h header file. */ /* #undef HAVE_NDIR_H */ -/* Define to 1 if your compiler conforms to the ANSI C standard. */ -#define HAVE_ANSI_COMPILER 1 - /* Define to 1 if you have the stdlib.h header file. */ #define HAVE_STDLIB_H 1 diff --git a/config.h.W32.template b/config.h.W32.template index 8d59a13..82d83ad 100644 --- a/config.h.W32.template +++ b/config.h.W32.template @@ -62,9 +62,6 @@ this program. If not, see http://www.gnu.org/licenses/. */ */ /* #undef HAVE_ALLOCA_H */ -/* Define to 1 if your compiler conforms to the ANSI C standard. */ -#define HAVE_ANSI_COMPILER 1 - /* Define to 1 if you have the 'atexit' function. */ #define HAVE_ATEXIT 1 diff --git a/configh.dos.template b/configh.dos.template index 61857ab..098fef5 100644 --- a/configh.dos.template +++ b/configh.dos.template @@ -76,9 +76,6 @@ this program. If not, see http://www.gnu.org/licenses/. */ /* Define to 1 if you have the select function. */ #define HAVE_SELECT 1 -/* Define to 1 if your compiler conforms to the ANSI C standard. */ -#define HAVE_ANSI_COMPILER 1 - /* Define to 1 if you have the stricmp function. */ #define HAVE_STRICMP 1 diff --git a/configure.ac b/configure.ac index c6a5482..8431143 100644 --- a/configure.ac +++ b/configure.ac @@ -64,12 +64,6 @@ AC_HEADER_TIME AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h string.h \ memory.h sys/param.h sys/resource.h sys/time.h sys/timeb.h]) -# Set a flag if we have an ANSI C compiler -AS_IF([test $ac_cv_prog_cc_stdc != no], -[ AC_DEFINE([HAVE_ANSI_COMPILER], [1], -[Define to 1 if your compiler conforms to the ANSI C standard.]) -]) - AM_PROG_CC_C_O AC_C_CONST AC_TYPE_SIGNAL -- 1.8.3.rc0.19.g7e6a0cc ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 'subdir-objects' would require sublter changes to several other parts of the build system that I don't know how to test properly. We should only enable the 'silent-rules' option for the moment. The updated patch below does this. Sorry for the noise, Stefano 8 8 8 8 8 8 8 8 From 46623411f017a447caa8fe75b3b42ec2fbeac458 Mon Sep 17 00:00:00 2001 Message-Id: 46623411f017a447caa8fe75b3b42ec2fbeac458.1367335124.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 30 Apr 2013 16:30:04 +0200 Subject: [PATCH] build: enable the '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 enable it by default, so better prepare ourselves. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- ChangeLog| 8 configure.ac | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 5278d49..ad5356c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + build: enable the '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 enable + it by default, so better prepare ourselves. + +2013-04-30 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + build: require Autoconf = 2.62 and Automake = 1.11.1 Older versions of those tools should be considered fully obsolete. diff --git a/configure.ac b/configure.ac index 548bc42..f2482c0 100644 --- a/configure.ac +++ b/configure.ac @@ -26,7 +26,7 @@ AC_CONFIG_SRCDIR([vpath.c]) AC_CONFIG_HEADERS([config.h]) # Automake setup -AM_INIT_AUTOMAKE([1.11.1]) +AM_INIT_AUTOMAKE([1.11.1 silent-rules]) # Checks for programs. AC_PROG_CC -- 1.8.3.rc0.19.g7e6a0cc ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting
On 04/29/2013 04:53 AM, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org 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 the default mode when parallel builds are running. I don't think we should do this unless users demand it, which means we should wait for the next release and some time beyond before making the decision. FWIW, I'm running 8-way parallel Make jobs for many months now, and never had any trouble interpreting their output, neither when they succeed, nor when they don't. The synchronized output operation annoys me slightly in that there are distinct time intervals when Make says nothing at all, and then the output appears in large chunks that get dumped en-masse to the screen. IOW, the user experience is different and takes time to get used to. FWIW, I agree with Eli. I think the new behaviour should not be made the default one. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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://savannah.gnu.org/bugs/?37307 I confess I didn't get a satisfactory answer to my question, of why the minimum version in configure.ac must be changed. It seems to me that if I build the make distribution tarball with a newer version of gettext, regardless of the minimum version specified in configure.ac, it should be good enough. I'm not sure of this -- I believe that gettext tries to use the data files for the version actually specified in AM_GNU_GETTEXT_VERSION, even when a more modern gettext is being used; for more details, see the commit message for this Automake commit http://git.savannah.gnu.org/cgit/automake.git/commit/?id=030ecb45 This seems confirmed by the Gettext manual: AM_GNU_GETTEXT_VERSION (in gettext.m4) -- The AM_GNU_GETTEXT_VERSION macro declares the version number of the GNU gettext infrastructure that is used by the package. See? There is no mention of minimal required version number --- it only speaks about *the* version number. Not sure if and how this is relevant for your situation, but might be something to consider. However, Brad was clear that he believed that the minimum version MUST be increased in configure.ac in order to get the benefits. I believe he's right, in light of the above. I was going to build with the new version anyway so I just changed it. If this is a problem we can get back into it and ask Brad for more clarification, and maybe check on the OpenBSD lists for details. Me goes back on lurking now... Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 stefano.lattar...@gmail.com CC: Eli Zaretskii e...@gnu.org, 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 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://savannah.gnu.org/bugs/?37307 I confess I didn't get a satisfactory answer to my question, of why the minimum version in configure.ac must be changed. It seems to me that if I build the make distribution tarball with a newer version of gettext, regardless of the minimum version specified in configure.ac, it should be good enough. I'm not sure of this -- I believe that gettext tries to use the data files for the version actually specified in AM_GNU_GETTEXT_VERSION, even when a more modern gettext is being used; Are you saying that, if AM_GNU_GETTEXT_VERSION specifies, say, 0.17, but the person who runs autoreconf has _only_ 0.18 installed, then autoreconf will fail because autopoint cannot find Gettext 0.17??? No. Unless I'm badly mis-reading the code in the autopoint script, gettext 0.x.y comes with the infrastructure files for *all* the versions = 0.x.y, and select which one to use based on the argument given to AM_GNU_GETTEXT_VERSION. for more details, see the commit message for this Automake commit http://git.savannah.gnu.org/cgit/automake.git/commit/?id=030ecb45 That commit message seems to also suggest a work-around, or maybe I'm missing something. This seems confirmed by the Gettext manual: AM_GNU_GETTEXT_VERSION (in gettext.m4) -- The AM_GNU_GETTEXT_VERSION macro declares the version number of the GNU gettext infrastructure that is used by the package. See? There is no mention of minimal required version number --- it only speaks about *the* version number. What happens if there's no AM_GNU_GETTEXT_VERSION call in configure.ac? I'm not sure, but I think gettext will bail out (again, this is based on my reading of the autopoint script, reading which might be wrong). Not sure if and how this is relevant for your situation, but might be something to consider. However, Brad was clear that he believed that the minimum version MUST be increased in configure.ac in order to get the benefits. I believe he's right, in light of the above. Even if he is, it is IMO wrong to punish everyone because of a single platform, whose problem is not really fatal (static linking). That is another matter altogether, which I have no opinion about :-) I'll leave to you to sort it out. And to reiterate: I'm no gettext expert, and my understanding of its behaviour might be skewed or wrong --- so don't trust any of my assertion above blindly, without proper double-checking. HTH, Stefano explanations above ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 stefano.lattar...@gmail.com --- ChangeLog | 9 + Makefile.DOS.template | 2 +- README.git| 4 ++-- build_w32.bat | 2 +- config.h-vms.template | 2 +- getloadavg.c | 2 +- 6 files changed, 15 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2e3458f..c494339 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2013-04-20 Stefano Lattarini stefano.lattar...@gmail.com (tiny change) + + * README.git: Our autoconf input file is 'configure.ac', not + 'configure.in'. Adjust accordingly. + * getloadavg.c: Likewise. + * build_w32.bat: Likewise. + * config.h-vms.template: Likewise. + * Makefile.DOS.template: Likewise. + 2013-04-16 Paul Smith psm...@gnu.org * misc.c (open_tmpfd): Add a new function that returns a temporary diff --git a/Makefile.DOS.template b/Makefile.DOS.template index 59c34a8..3ec01be 100644 --- a/Makefile.DOS.template +++ b/Makefile.DOS.template @@ -122,7 +122,7 @@ man1dir = $(mandir)/man1 MANS = $(man_MANS) NROFF = nroff -DIST_COMMON = README ABOUT-NLS AUTHORS COPYING ChangeLog INSTALL Makefile.am Makefile.in NEWS acconfig.h aclocal.m4 alloca.c build.sh-in config.h-in configure configure.in getloadavg.c +DIST_COMMON = README ABOUT-NLS AUTHORS COPYING ChangeLog INSTALL Makefile.am Makefile.in NEWS acconfig.h aclocal.m4 alloca.c build.sh-in config.h-in configure configure.ac getloadavg.c DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST) diff --git a/README.git b/README.git index 82c33e5..59ab090 100644 --- a/README.git +++ b/README.git @@ -61,7 +61,7 @@ Building From Git To build GNU make from Git, you will need Autoconf, Automake, and Gettext, and any tools that those utilities require (GNU m4, Perl, -etc.). See the configure.in file to find the minimum versions of each +etc.). See the configure.ac file to find the minimum versions of each of these tools. You will also need a copy of wget. When building from Git you must build in the source directory: VPATH @@ -149,7 +149,7 @@ Steps to Release Here are the things that need to be done (in more or less this order) before making an official release: - * Update the configure.in file with the new release number. + * Update the configure.ac file with the new release number. * Update the NEWS file with the release number and date. * In Savannah modify the Value, Rank, and Description values for the current SCM entry in both Component Version and Fix Release fields diff --git a/build_w32.bat b/build_w32.bat index 36aeea3..fa60927 100644 --- a/build_w32.bat +++ b/build_w32.bat @@ -16,7 +16,7 @@ rem You should have received a copy of the GNU General Public License along rem with this program. If not, see http://www.gnu.org/licenses/. if exist config.h.W32 GoTo NotSCM -sed -n s/^AC_INIT(\[GNU make\],\[\([^]]\+\)\].*/s,%%VERSION%%,\1,g/p configure.in config.h.W32.sed +sed -n s/^AC_INIT(\[GNU make\],\[\([^]]\+\)\].*/s,%%VERSION%%,\1,g/p configure.ac config.h.W32.sed echo s,%%PACKAGE%%,make,g config.h.W32.sed sed -f config.h.W32.sed config.h.W32.template config.h.W32 :NotSCM diff --git a/config.h-vms.template b/config.h-vms.template index e5e623c..de7665e 100644 --- a/config.h-vms.template +++ b/config.h-vms.template @@ -16,7 +16,7 @@ You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. */ /* config.h. Generated automatically by configure. */ -/* config.h.in. Generated automatically from configure.in by autoheader. */ +/* config.h.in. Generated automatically from configure.ac by autoheader. */ /* Define to 1 if on AIX 3. System headers sometimes define this. diff --git a/getloadavg.c b/getloadavg.c index dfc2e4a..11476b7 100644 --- a/getloadavg.c +++ b/getloadavg.c @@ -22,7 +22,7 @@ this program. If not, see http://www.gnu.org/licenses/. */ macro that comes with autoconf 2.13 or newer. If that isn't an option, then just put AC_CHECK_FUNCS(pstat_getdynamic) in your - configure.in file. + configure.ac file. FIXUP_KERNEL_SYMBOL_ADDR() Adjust address in returned struct nlist. KERNEL_FILE Pathname of the kernel to nlist. LDAV_CVT() Scale the load average from the kernel. -- 1.8.2.1.389.gcaa7d79 ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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] Error 1 make[3]: Leaving directory `/devel/bleeding/src/make/po' make[2]: *** [cs.po] Error 2 OTOH, if I re-run configure with the '--disable-nls' option, the build and the testsuite succeeds. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 revision 1.79 diff -r1.79 make.texi 8890c8890 @itemx --no-print-directory --- @item --no-print-directory ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 remember that there had been talks about a $(.TARGETS) special variable in the past, but for some reasons that had been problematic to implement correctly, and the idea was (at least temporarily) dropped. Perhaps the ability to detect if a target is defined and another to remove it would offer a complete api. But note that I'm just proposing to remove the *recipe* associated with a target, not the target itself (nor the list of dependencies for it). Not that I oppose such an enhancement, but is distinct from what I need for my use case (and might be more tricky to implement). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 recipe. I was speaking only about changing such associated recipe, which GNU make is apparently able to do right today, albeit unconditionally printing a warning when it does so. It's because of this pre-existing ability that I suspect and hope it would be feasible to implement my originally proposed feature. We can already add targets but not the other two. Actually, we can already add targets *but not* remove nor detect them, and we can already add recipes *and* override them (we just cannot do so avoiding warnings), but OTOH we cannot detect (not that I know of). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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-written) makefile, it is useful to be able to seamlessly override some of the recipes defined in those fragments from the master makefile. My Automake fork Automake-NG (whose generated Makefiles only target GNU make) could certainly take great advantage of such an ability in the future (near future in fact). I'm not sure what be the best way to implement my proposed feature. Some random ideas: - an all-encompassing option --no-warn-rule-override, that would suppress *all* warnings about overridden rules; - a new special target .OVERRIDABLE-RECIPES:, that would suppress the override warnings only for the rules specified as its prerequisites; - a new built-in to explicitly instruct make to clear the rule(s) so far associated to a target: $(clear-rules TARGET) This approach has the advantage of being very explicit, and to allow clearing of not only for normal rules, but also double-colon ones. - a new syntax to define special kind of rule for a given target -- a rule which can be silently overridden later; e.g., TARGET ?: commands that will be overridden ... TARGET : actual commands Note that I include this latter approach only for completeness; I rather dislike it, because it doesn't give enough power to the user -- the writer of the original makefile must decide statically and beforehand which rules to make overridable. Thoughts, objections, feedback? Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 ruleA version 2 endef $(eval $(call ruleA,...)) Thanks for the tip. And now that I think about it, an even simpler and clearer idiom would be using GNU make ability of recipe canning http://www.gnu.org/software/make/manual/make.html#Canned-Recipes (which is a great, great feature IMO): define rule-foo do something @do something else, hiding the recipe do something else; \ that spans \ multiple lines endef define rule-bar @cmd1 @cmd2 endef ... # Then later ... foo bar: $(rule-$@) However, even my simplified idiom, if used throughout, would rapidly render the makefile library I was hinting to more cumbersome to write and to understand than I'd like; having a more native way to obtain the intended effect would be better. I guess in the end it will boil down to: is it be easier to consistently use the idiom above, or to enhance GNU make to implement my feature request? 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 question. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 stefano.lattar...@gmail.com 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 question. Yes, and I hope you get your feature. But consider that auto-tools are traditionally targeted at the lowest common denominator. You've made an explicit exception for Automake-NG that it will require GNU make, which is reasonable. But do you really want to require a not-yet-even-released version? No. But the nice thing is that we can support 3.81 and later if we accept graceful degradation: that is, make versions = 3.82 will print an override warnings unconditionally (annoying, but bearable), while versions = 3.83 will respect explicit user overrides, without any spurious/redundant diagnostic. And the more the time passes, the more the situation will improve (since more and more people will be using 3.83 or later in the future). That might not become generally available for a decade or so, depending how portable you want to be. It seems to me that targeting 3.81 or so would be better. IMHO. That is currently our own target, yes (but I'm ready to just assume make 3.82 or later if the first stable Automake-NG version will be more than eight months from now). The argument about graceful degradation given above shows that is not a problem in practice. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. How to reproduce: $ make V=' x' -f - 'all:; test $(V) = x' test x = x make: *** [all] Error 1 $ echo $? 1 The issue is not present for values inherited from the environment: $ V=' x' make -f - 'all:; test $(V) = x' test x = x $ echo $? 0 $ V=' x' make -e -f - 'all:; test $(V) = x' test x = x $ echo $? 0 Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 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 forcing the target to be updated if one of those rules is executed. But if I write a makefile like this: ALL = a b c d default: echo Specify a target: $(ALL); exit 1 .PHONY: $(ALL) $(ALL): @echo $@ a: | b b: | c c: | d then I get: $ make a # Not what I expected, but what actually happened. d c b a which is not what I'd have expected reading the documentation above; what I would have expected was that a alone would be run: $ make a # What I expected, but did not happen. a No, that's not how order-only prerequisites work. An order-only prerequisite is treated identically to a normal prerequisite except for exactly one thing: when make checks to see if a target needs to be remade, the time-last-modified values for any order-only prerequisites are not considered. Ah, all is clear now. Then I think we are dealing with a documentation bug here; in particular: - the name order-only prerequisites is IMHO poorly chosen, and don't really correspond to their actual semantics; a more appropriate might be weak prerequisites or existence-only prerequisites; - the explanation given in the manual is imprecise and confusing; since the explanation you've given here is OTOH very clear and concise, I suggest you report it in the manual; - it might make sense to state explicitly that order-only prereqs which are phony behaves in all ways like standard prerequisites. However, they are still considered prerequisites in that they are still built, themselves, if necessary, before the target. Since your targets are all phony (and none of them update their target file either) they will all always be remade every time. You can't see how order-only prerequisites work using this makefile. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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
stefano.lattar...@gmail.com 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
I am trying to solve rather than just the attempts I've made at solving it.
Is there an easy, scalable way to specify in a GNUmakefile that, whenever
two given targets T1 and T2 (either phony or not) are to be updated, T1's
recipe must be executed before T2's, all without declaring any dependency
of T2 on T1? So that for example, assuming T1 and T2 are both phony:
$ make T1 # Only run T1's recipe
$ make T1 # Only run T2's recipe
(I think you meant make T2 there...)
Yes, sorry.
$ make T2 T1 # Run T1's recipe, then T2's recipe
$ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe
I think I would use a test on $(MAKECMDGOALS) to make T1 a
prerequisite of T2 if and only if T1 is a goal, say...
ifneq ($(filter T1,${MAKECMDGOALS}),)
T2: T1
endif
Not good enough; the order dependency I want between T1 and T2 should
have to work also when they are updated as dependencies of other targets:
$ cat Makefile
all: T1 T2
...
$ make all # Ought to work executing T1 before T2.
Regards,
Stefano
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
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 forcing the target to be updated if one of those rules is executed. But if I write a makefile like this: ALL = a b c d default: echo Specify a target: $(ALL); exit 1 .PHONY: $(ALL) $(ALL): @echo $@ a: | b b: | c c: | d then I get: $ make a # Not what I expected, but what actually happened. d c b a which is not what I'd have expected reading the documentation above; what I would have expected was that a alone would be run: $ make a # What I expected, but did not happen. a OTOH, if I had invoked more than one prerequisite at the same time, I'd have expected the ordering among them to be respected, like this: $ make b a c # What would I expected. c b a Is this a bug in make, in its documentation, or it's just me misunderstanding something? Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 stefano.lattar...@gmail.com wrote: 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 forcing the target to be updated if one of those rules is executed. But if I write a makefile like this: ALL = a b c d default: echo Specify a target: $(ALL); exit 1 .PHONY: $(ALL) What is your intent for declaring all the targets PHONY in this Makefile? 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 I am trying to solve rather than just the attempts I've made at solving it. Is there an easy, scalable way to specify in a GNUmakefile that, whenever two given targets T1 and T2 (either phony or not) are to be updated, T1's recipe must be executed before T2's, all without declaring any dependency of T2 on T1? So that for example, assuming T1 and T2 are both phony: $ make T1 # Only run T1's recipe $ make T1 # Only run T2's recipe $ make T2 T1 # Run T1's recipe, then T2's recipe $ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe (Note: to quote 4.6 Phony Targets: A phony target should not be a prerequisite of a real target file; if it is, its recipe will be run every time `make' goes to update that file. As long as a phony target is never a prerequisite of a real target, the phony target recipe will be executed only when the phony target is a specified goal (*note Arguments to Specify the Goals: Goals.). ) Philip Guenther Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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.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 :-( 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? Maybe 'can-have-lazy-variables'? (I know, I suck at choosing names). Update: this won't actually be required anymore by Automake-NG, since I've somehow managed (mostly by chance and random tweaking) to find an idiom that works also with the older GNU make versions: http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00067.html Better again: would you consider the possibility of adding a new kind of variables (let's call them lazy), so that a definition like: LAZYVAR = val behaves exactly as: LAZYVAR = $(override LAZYVAR := val)$(LAZY) But I still think having this feature built into GNU make would be valuable (even though Automake-NG won't use it right away). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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? Maybe 'can-have-lazy-variables'? (I know, I suck at choosing names). I'm not interested in having the features option used to describe bugs that have been fixed, sorry. No problem, I've apparently managed to find a work-around for the issue, so I won't need this new .FEATURES entry anyway (I had already retired the request in my other, earlier reply). It should be straightforward to find some real feature added in the release where the bug is fixed though and you can check for that instead. Better again: would you consider the possibility of adding a new kind of variables (let's call them lazy), so that a definition like: LAZYVAR = val behaves exactly as: LAZYVAR = $(override LAZYVAR := val)$(LAZY) I don't have any idea what this is supposed to do... it doesn't make any sense as written. In fact, it should have been s/$(LAZY)/$(LAZYVAR)/. Sorry for the confusion. Can you describe in words what you're looking for? Basically, a new kind of assignment that do not expand the right-hand side at definition time, but which causes the value the variable expands to the first time it gets dereferenced to be cached, and reused in any successive expansion of that same variable. A sort of memoized variables, if you want. A rationale for this request is given by the commit message of this patch: http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00067.html Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 = \ \ \ \ \ \ \ \ \ var = $(eval var := $$(mufoofoo))$(var) dummy: : $(firstword $(var)) Running the above, make dies with the following message: Makefile:13: *** unterminated variable reference. Stop. And any of the following minimal and *apparently irrelevant* changes to the Makefile above that cause the error to disappear: - changing 'var' with 'va' everywhere - changing 'mufoofoo' with 'mfoofoo' - removing *just one 'x'* from the value of mufoofoo Any idea of what's going on here? Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 :-( Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 bad this bug will prevent me from using the lazy-evaluation trick with any GNU make 3.83 :-( 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? Maybe 'can-have-lazy-variables'? (I know, I suck at choosing names). Better again: would you consider the possibility of adding a new kind of variables (let's call them lazy), so that a definition like: LAZYVAR = val behaves exactly as: LAZYVAR = $(override LAZYVAR := val)$(LAZY) WDYT? Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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://git.savannah.gnu.org/cgit/automake.git http://git.savannah.gnu.org/cgit/gnulib.git http://git.savannah.gnu.org/cgit/grep.git http://git.savannah.gnu.org/cgit/sed.git http://git.savannah.gnu.org/cgit/gawk.git http://git.savannah.gnu.org/cgit/m4.git http://git.savannah.gnu.org/cgit/tar.git http://git.savannah.gnu.org/cgit/diffutils.git http://git.savannah.gnu.org/cgit/findutils.git http://git.savannah.gnu.org/cgit/bison.git (and probably some other more). And GCC has an *official* Git mirror as well: git://gcc.gnu.org/git/gcc.git (but its main repo is still in SVN if I'm not mistaken) Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 of this if you have to modify every makefile to add the special target. Not completely true. A developer using Automake who wants to take advantage of this feature could just add the line: .PARALLELSYNC: to his Makefile.am file(s). Automake's preprocessing policy is to pass through the things it doesn't understand (or that are not influential to it). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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. with binary non-printable characters or with special character sequences. By redirecting the output to files, then displaying it on the screen, the output may look strangely, or have some more grave effect, like terminating output prematurely. We should consider these potential problems, and in any case the simple loop that reads from temporary files and writes to stdout/stderr may need to become much more complicated, at least on DOS/Windows. (I believe similar, though less serious, problems could happen on Unix as well.) For a real-life example of a (minor) problem of this kind that we have encountered in Automake, see: http://www.mail-archive.com/automake-patches@gnu.org/msg03641.html Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 $@ $(foo_OBJECTS) .c.o: $(CC) -c -o $@ $ $ ls ../src foo.c $ make make: *** No rule to make target `src//foo.o', needed by `foo'. Stop. Changing the definition of `foo_OBJECTS' to `./src/foo.o' solves the problem. A complete script that reproduces the bug is attached. The script fails with GNU make (versions 3.79, 3.80 and 3.81) on Debian GNU/Linux and with GNU make 3.81 on Solaris 10. On the other hand, it passes with Solaris 10's /usr/ccs/bin/make and with FreeBSD make. Let me know if you need more details. Regards, and thanks for all your work on GNU make. Stefano gmake-bug.sh Description: application/shellscript ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
