Re: GNU make troubleshooting

[Philip Guenther]

I just put this at the very end of top makefile:

${MAKEFILE_LIST}: ;

Philip Guenther

On Sun, Jul 16, 2023 at 12:25 PM Torbjorn SVENSSON <
torbjorn.svens...@foss.st.com> wrote:

>
>
> On 2023-07-16 15:58, Alejandro Colomar wrote:
> > Wow!  That's a great help for debugging the Linux man-pages's makefiles,
> > which don't need to be remade.  It was very painful to me to ignore so
> > much make -d output.  I applied the following patch, and it works like
> > a charm.
> >
> > <
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=c98d237c22e9e898ae7d05ee7eac47791bd3
> >
>
> Why are you wasting time doing grep when you can have find return just
> those files that ends with .mk? Also, why need to sort the list when
> it's only for make to define a rule?
>
> I would have done something along these lines if I were in your shoes:
>
> MK := $(srcdir)/Makefile
> MK += $(shell $(FIND) $(MAKEFILEDIR) -type f -name '*.mk')
>
>
> Or, a more cleaner solution would have been to define the MK-array in
> the $(srcdir)/Makefile as you have it hard coded for the include
> statements now.
>
> MK :=   \
> $(MAKEFILEDIR)/check/_.mk   \
> $(MAKEFILEDIR)/check/catman.mk  \
> $(MAKEFILEDIR)/build/_.mk   \
> $(MAKEFILEDIR)/build/catman.mk  \
> $(MAKEFILEDIR)/build/html.mk\
> $(MAKEFILEDIR)/build/pdf.mk \
> $(MAKEFILEDIR)/build/pre.mk \
> $(MAKEFILEDIR)/build/ps.mk  \
> $(MAKEFILEDIR)/build/src.mk \
> $(MAKEFILEDIR)/dist.mk  \
> $(MAKEFILEDIR)/install/_.mk \
> $(MAKEFILEDIR)/install/html.mk  \
> $(MAKEFILEDIR)/install/man.mk   \
> $(MAKEFILEDIR)/lint/_.mk\
> $(MAKEFILEDIR)/lint/c.mk\
> $(MAKEFILEDIR)/lint/man/_.mk\
> $(MAKEFILEDIR)/lint/man/man.mk  \
> $(MAKEFILEDIR)/lint/man/mdoc.mk \
> $(MAKEFILEDIR)/make.mk  \
> $(MAKEFILEDIR)/verbose.mk
>
> include $(MK)
> $(srcdir)/Makefile $(MK):: ;
>
>
> Kind regards,
> Torbjörn
>
>

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Philip Guenther]

Is make being built with -D_FILE_OFFSET_BITS=64 to use the large-file
APIs?  If not, then maybe the problem is an inode number that doesn't fit
in the old 32-bit ino_t that some struct dirent's were stuck with.  Check
the output of "ls -l -i" (note the -i option!) to see if there's an inode
number larger than 2billion in the output, like the '..' directory entry
from the NFS parent filesystem...

(You have less than 16 years of use on that Solaris 8 box, as it still has
a 32-bit time_t, which wraps in Jan 2038.  Type fast!)

Philip

On Mon, Nov 7, 2022 at 8:17 PM anonymous  wrote:

> Follow-up Comment #4, bug #63330 (project make):
>
> It looks like this is somehow related to NFS.  I was running the
> newly-generated make in the root of the source tree, and on an NFS mounted
> directory it fails immediately.  If I copy the tree to a local directory I
> have no problems.
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
> Message sent via Savannah
> https://savannah.gnu.org/
>
>
>

Re: [bug #63307] make 4.4 passes ignored SIGPIPE on to children

[Philip Guenther]

On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov 
wrote:

> Follow-up Comment #6, bug #63307 (project make):
>
> > If SIGIGN was ignored before make was started though, it should remain
> ignored, even for make's children, see also
>  in
> reply
> to Andreas Schwab's first patch. Correct me if I am wrong, but I think your
> patch re-enables it in that case?
>
> My patch causes the disposition of sigpipe to be set to SIG_DFL in the new
> process. See https://pubs.opengroup.org/onlinepubs/9699919799/,
> specifically
> "Signals set to be caught by the calling process image shall be set to the
> default action in the new process image (see )."
>
> This desire to have the default disposition is intentional. Some of the
> reasons are explained in update 2. Other reasons are the desire to avoid
> complexity in make. Especially when there is no clear need for that
> complexity.
>

This is a change in behavior: previously, make didn't alter the disposition
of SIGPIPE and a build system could set it to SIG_IGN and have all the
invoked recipes inherit that.  As part of saying that make will ignore
SIGPIPE, you've decided to impose a rule that the rest of the build system
has to deal with it in the recipes instead of permitting a pass-through.
That's an unnecessary and user-unfriendly imposition.


In regards to the specific impl of Andreas's 2nd patch there are 2 points.
>
> 1. That patch fails to restore the disposition in the case of make
> re-executing itself (in order to read an updated makefile).
> This could be fixed by calling sigaction before execve, but that'd not be
> atomic.


> 2. That patch uses posix_spawnattr_setsigdefault to set the disposition
> for a
> child process (when make uses posix_spawn). This fails the purpose of the
> patch, if make was invoked with sigpipe disposition of SIG_HOLD.
>

(SIG_HOLD?  That's not a real disposition (in posix) but rather part of an
obsolete version of a mechanism standardized as sigprocmask() and
orthogonal to the disposition (ignore/default/catch).)



> Fixing those deficiencies is not that cheap. In the end, i didn't see any
> benefit for make to go through that trouble of restoring sigpipe
> disposition
> for its children and i proposed this simple fix.
>
> Unlike attempts to restore, one nice property of the sighandler patch is
> that,
> if more calls to exec are introduced to make, the patch will still work for
> all of them.
>

Setting the disposition of SIGPIPE to be caught with a do-nothing routine
is a good idea.  Can you just skip that if the disposition is SIG_IGN at
start?  Then a SIG_IGN will be inherited but the disposition will otherwise
be reset by execve.

Re: please keep up supporting AmigaOS

[Philip Guenther]

Well, the good news is that you have lots of volunteers to test new
versions where you refactor the code to reduce the intrusiveness of the
Amiga changes!

"Hi, you expressed interest in GNU make continuing to support your OS;
here's where you help us reduce the burden of that."  :)

Philip Guenther


On Thu, Nov 3, 2022 at 9:39 AM Paul Smith  wrote:

> On Thu, 2022-11-03 at 19:06 +0100, Henrik Carlqvist wrote:
> > Thank you for joining the group of Amiga users that now are spamming
> > all the subscribers of the GNU mailing list.
>
> It's unfortunate that I asked for responses to the bug-make list
> instead of to my private account: I sort of assumed that folks who
> built "AmigaOS distributions" (etc.) would send a reply if they wanted
> to take on responsibility.
>
> It appears that this info got posted on one or more Amiga news
> aggregators and hence the response from many Amiga users.
>
> I am replying to these messages privately but we'll just have to live
> with the onslaught: these folks don't realize there have already been
> many requests.
>
> Sorry about that!
>
>

Re: [PATCH] [SV 63307] Unignore SIGPIPE in spawned children

[Philip Guenther]

make should note whether SIGPIPE is ignored on entry and, if so, then it
should leave it ignored when it invokes other programs and not
unconditionally set SIGPIPE to SIGDFL.

Philip Guenther


On Wed, Nov 2, 2022 at 6:29 AM Andreas Schwab  wrote:

> * configure.ac: Check for posix_spawnattr_setsigdefault.
> * src/job.c (child_execute_job): Set SIGPIPE to default in the
> child process.
> ---
>  configure.ac |  2 +-
>  src/job.c| 18 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 9f688971..30eb2d55 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -134,7 +134,7 @@ AC_CHECK_FUNCS([strtoll strdup strndup stpcpy memrchr
> mempcpy umask mkstemp \
>  getgroups seteuid setegid setlinebuf setreuid setregid \
>  mkfifo getrlimit setrlimit setvbuf pipe strerror
> strsignal \
>  lstat readlink atexit isatty ttyname pselect posix_spawn \
> -posix_spawnattr_setsigmask])
> +posix_spawnattr_setsigmask posix_spawnattr_setsigdefault])
>
>  # We need to check declarations, not just existence, because on Tru64 this
>  # function is not declared without special flags, which themselves cause
> diff --git a/src/job.c b/src/job.c
> index b78f279c..621ff899 100644
> --- a/src/job.c
> +++ b/src/job.c
> @@ -2305,6 +2305,11 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>/* We are the child.  */
>unblock_all_sigs ();
>
> +  /* Unignore SIPIPE.  */
> +#ifdef SIGPIPE
> +  bsd_signal (SIGPIPE, SIG_DFL);
> +#endif
> +
>  #ifdef SET_STACK_SIZE
>/* Reset limits, if necessary.  */
>if (stack_limit.rlim_cur)
> @@ -2347,6 +2352,19 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>}
>  #endif /* have posix_spawnattr_setsigmask() */
>
> +  /* Unignore SIGPIPE.  */
> +#ifdef HAVE_POSIX_SPAWNATTR_SETSIGDEFAULT
> +  {
> +sigset_t mask;
> +sigemptyset ();
> +sigaddset (, SIGPIPE);
> +r = posix_spawnattr_setsigdefault (, );
> +if (r != 0)
> +  goto cleanup;
> +flags |= POSIX_SPAWN_SETSIGDEF;
> +  }
> +#endif
> +
>/* USEVFORK can give significant speedup on systems where it's
> available.  */
>  #ifdef POSIX_SPAWN_USEVFORK
>flags |= POSIX_SPAWN_USEVFORK;
> --
> 2.38.1
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
>

Re: Implicit rule for linking multiple object files

[Philip Guenther]

The first place to consult in understanding how to build your code is the
documentation of your compiler.  C++20 *module* support is very new in at
least gcc and they have not provided direct guidance on how to use modules
with 'make', at least I don't see any such guidance here:

https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/C_002b_002b-Modules.html#C_002b_002b-Modules

Instead they have a link to an outside whitepaper.  Ideally, the gcc
developers would work with the GNU make developers to provide rules and
documentation that would solve your problems.  They have not yet done so.
Your choices are:
 * to work it out
 * to wait until they provide that guidance
 * to find another compiler and/or build system

To be blunt, the questions you're asking about make behavior indicate that
it will require a dedicated effort for you to develop the correct rules
yourself.  While at least one workaround has already been proposed (declare
a.o, b.o, c.o, and d.o. as prerequisites of main.o) that is almost
certainly specific to the modules and classes involved here and if this
project grows a more complex module/class layout additional, possibly
conflicting rules will be required.  A solution which is robust to future
code/design changes really requires a broad view of the dependency
structure of the C++ module implementation...which is where guidance from
the C++ compiler developers would *really* be useful.

Good luck.

Philip Guenther


On Wed, Aug 10, 2022 at 9:19 PM ljh  wrote:

> Hi Paul,
>
> I don't know if this is related to gcc support of c++20.
> But mentioning target.o ("x.o") and recipe or not in my Makefile, does
> have different result. My test follows.
>
> Thanks
>
>
> ---
>
> 1. error: with target.o ("x.o"), without recipe
>
>
> $ ls
>  a.cpp   b.cpp   c.cpp   d.cpp   main.cpp   Makefile
> $
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o main.o
> #   $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o main.o main.cpp
> In module imported at main.cpp:1:1:
> A: error: failed to read compiled module: No such file or directory
> A: note: compiled module file is ‘gcm.cache/A.gcm’
> A: note: imports must be built before being imported
> A: fatal error: returning to the gate for a mechanical issue
> compilation terminated.
> make: *** [: main.o] Error 1
> $
>
>
> 2. ok: without target.o and recipe
>
>
> $ rm -fr *.o gcm.cache main
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o # main.o
> #   $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o c.o c.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o b.o b.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o a.o a.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o d.o d.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g main.cpp c.o b.o a.o d.o
>   -o main
> $
>
>
> 3. ok: with target.o and recipe
>
>
> $ rm -fr *.o gcm.cache main
> $ cat Makefile
> CXXFLAGS = -Wall -Wextra -std=c++2a -fmodules-ts -g # -O3 -fPIC
> main : c.o b.o a.o d.o main.o
> $(CXX) $^ -o $@
> $ make
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o c.o c.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o b.o b.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o a.o a.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o d.o d.cpp
> g++ -Wall -Wextra -std=c++2a -fmodules-ts -g-c -o main.o main.cpp
> g++ c.o b.o a.o d.o main.o -o main
> $
>
> $ make --version
> GNU Make 4.3
> Built for x86_64-pc-linux-gnu
> Copyright (C) 1988-2020 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.
> $
>
>
> -- 原始邮件 --
> *发件人:* "psmith";
> *发送时间:* 2022年8月11日(星期四) 凌晨2:31
> *收件人:* "ljh"; "bug-make";
> *主题:* Re: Implicit rule for linking multiple object files
>
> On Thu, 2022-08-11 at 01:58 +0800, ljh wrote:
> > I have three c source files: x.c, y.c, z.c and I name x as the target
> > on left. Can I put x.o in the prerequisites on the right too? Are
> > they the same, with or without x.o in the prerequisites on the right?
> >
> > x: y.o z.o x.o  # with x.o
>
> It is correct to do this.
>
> These two rules do not behave exactly the same:
>
>   x: y.o z.o
>
> versus
>
>   x: y.o z.o x.o
>
> (you can see the difference for yourself by running "make" both ways)
&

Re: Goodbye to GNU make's "build.sh" ... ?

[Philip Guenther]

On Sat, Jun 25, 2022 at 12:48 PM Paul Smith  wrote:

> I'm trying to decide what the future is for GNU make's "build.sh"
> bootstrapping script. As you may recall, this script is provided to
> allow GNU make to build on systems which don't already have an instance
> of make installed. Its goal is to build the first make binary, without
> of course all the fancy parts of avoiding rebuilds, generating
> dependency files, etc.
>

Can anyone contribute information about actual cases where build.sh was
used?

I've been using GNU make since 1992 or so, on only 9 or so different  UNIX
platforms, but they all had _some_ form of make available, however
crippled, that was sufficient to bootstrap GNU make.  So, I've avoided
being its target audience.  Who has been and can they speak to what they
would do without it?  "I have a native compiler, but not make" is kinda a
weird place to be; those bootstrapping a new OS typically cross-compile the
entire toolchain until they can self-host: make is just another small divot
in that bumpy road and using build.sh when they still have to cross-compile
the rest of the toolchain doesn't actually help.


This leaves me with two options:
>
>1. Stop using gnulib, or at least sharply limit the modules we will
>   include to those with trivial-enough configurations.
>2. Abandon the build.sh script and require an existing make program
>   in order to build a new version of GNU make.


Lacking a description of a case in the past where build.sh was actually the
only sane option, I would go with #2.


Philip Guenther

Re: sub makefile does not use correct value of CFLAGS from top make file,

[Philip Guenther]

Unlike variable assignments, rules--including overrides of built-in pattern
rules--are not inherited by recursively invoked instances of make.  They
have to be in a makefile read by the instance of make that needs them.

(GNU makes built-in rules and variables have TARGET_ARCH for basically all
types of compilation.  IMHO, if you have options that don't apply to, for
example, .S files, then why not put them in CFLAGS *directly* and not in
TARGET_ARCH?  Or just use your own variable name (e.g., "targ_arch")
instead of trying to give your own use/meaning to a variable which is
already in use.  Fighting the builtin rules is a bad use of your time.)


Philip Guenther

On Fri, Sep 3, 2021 at 12:58 PM Jeffrey.Fellin--- via Bug reports and
discussion for GNU make  wrote:

> I have a project that compiles .S and .c files, and the value of CFLAGS in
> the sub makefile is not the same for the compile lines
>
>
>
> The version of make is
>
> GNU Make 3.82
>
> Built for x86_64-redhat-linux-gnu
>
> Copyright (C) 2010  Free Software Foundation, Inc.
>
>
>
> I’m attaching a tarball containing the following files, for ease in
> reproducing the problem
>
> cflags_bug/make_top
>
> cflags_bug/base/sub_make
>
> cflags_bug/base/src/bug.S
>
> cflags_bug/base/src/hello.c
>
>
>
> The compile of bug.S succeeds, but doesn’t have the correct value of
> CFLAGS, as in the annotated output below. The compile of hello.c has the
> correct value of CFLAGS, but the compile fails due to the unsupported
> options to the cc. The extra options are for use by the project specific
> compiler.
>
>
>
> The top make undefines the default rules for %.o:%.c and %.o:%.S, has my
> understanding from these documents:
>
> Managing Projects with BNU Make, Third Edition,
>
> GNU Make pdf, Section 10.5.5 Match-Anything Pattern Rules
>
>
>
> The annotated execution of make -f make_top, supplied in the cflags_bug.tar
>
> $ make -ikf make_top;exit
>
> (cd base && make -f sub_make all)
>
> make[1]: Entering directory `/home/jfellin/cflags_bug/base'
>
> # This displays the value of CFLAGS that should be use in the
>
> # compilation of the .S and .c files
>
> # the compile errors are not important, but the different
>
> # value of CFLAGS, which are expected to be the same.
>
>
>
> # Also note the top make file removes the default rule for %.o:%.[Sc], but
>
> # the default rules are still being used.
>
>
>
> # Expected value in compile *.S and *.c
>
> check CFLAGS=-DTOP_MAKE -Wall -I base/inc -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None-O  -MD -I
> /home/jfellin/cflags_bug/base/../base/inc  -D BASE_MAKE
>
>
>
>
>
> # Note this value of CFLAGS is not the one printed above
>
> cc-c -o /home/jfellin/cflags_bug/base/../base/src/bug.o
> /home/jfellin/cflags_bug/base/../base/src/bug.S
>
>
>
>
>
> # Note this value of CFLAGS is the one printed by the check_cflag rule
>
> # in the file, sub_make,
>
> cc -DTOP_MAKE -Wall -I base/inc -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None-O  -MD -I
> /home/jfellin/cflags_bug/base/../base/inc  -D BASE_MAKE  -mlittle-endian
> --target=aarch64-arm-none-eabi -mcpu=cortex-a53+nocrypto+nofp+nosimd
> -mno-unaligned-access -mfpu=None -c -o
> /home/jfellin/cflags_bug/base/../base/src/hello.o
> /home/jfellin/cflags_bug/base/../base/src/hello.c
>
> cc: warning: \u2018-mcpu=\u2019 is deprecated; use \u2018-mtune=\u2019 or
> \u2018-march=\u2019 instead
>
> cc: warning: \u2018-mcpu=\u2019 is deprecated; use \u2018-mtune=\u2019 or
> \u2018-march=\u2019 instead
>
> cc: error: unrecognized command line option \u2018-mlittle-endian\u2019
>
> cc: error: unrecognized command line option
> \u2018-mno-unaligned-access\u2019
>
> cc: error: unrecognized command line option \u2018-mfpu=None\u2019
>
> cc: error: unrecognized command line option \u2018-mlittle-endian\u2019
>
> cc: error: unrecognized command line option
> \u2018-mno-unaligned-access\u2019
>
> cc: error: unrecognized command line option \u2018-mfpu=None\u2019
>
> make[1]: [/home/jfellin/cflags_bug/base/../base/src/hello.o] Error 1
> (ignored)
>
> make[1]: Leaving directory `/home/jfellin/cflags_bug/base'
>
>
>
> Jeff
>
>
>

Re: GNU make man page typo

[Philip Guenther]

On Thu, Sep 2, 2021 at 5:07 AM Zach Petch  wrote:

> This is minor in the grand scheme of things, but I noticed a typo in the
> man page for GNU make. In case it makes a difference, I was on a Mac
> running macOS Big Sur 11.5.2 when I came across the typo.
>
> The second paragraph under DESCRIPTION reads,
>
> > To prepare to use make, you must write a file called the makefile that
> describes the relationships among files in your program, and the states the
> commands for updating each file.
>
> It appears that the first use of "the" after the second comma should
> either be "then" or quite possibly should simply not exist at all. That
> portion of the sentence would then read either,
>
> > and then states the commands for updating each file
>
> or,
>
> > and states the commands for updating each file
>
> and would, at the very least, reduce the likelihood of people like myself
> (who need to read slowly and carefully to understand things like man pages)
> from getting temporarily tripped up by the wording of that line.
>
> I recognize that this is minor and somewhat pedantic, but I appreciate you
> taking the time to read this.
>

I'm pretty sure that it was a typo/thinko for "that states", making the
full sentence:

To prepare to use make, you must write a file called the makefile that
describes the relationships among files in your program and that states the
commands for updating each file.


I also think the second comma is incorrect ("comma splice") and suggest
removing it as seen above: even the 'Oxford comma' rule only applies to
lists of three or more items.

Philip Guenther

Re: [bug] Sibling submakes: wait for other submakes before failing

[Philip Guenther]

On Sun, Jun 13, 2021 at 6:29 PM David A. Wheeler 
wrote:

> > On Jun 13, 2021, at 5:44 PM, Alejandro Colomar (man-pages) <
> alx.manpa...@gmail.com> wrote:
> >
> > Let's say there's a project with a submake for each module.
>
> It’s counter-intuitive, but it is usually *MUCH* faster & more accurate to
> have a single make process
> figure things out in most cases than to use recursive makes.
>
> For more info, see “Recursive make considered harmful” by Peter Miller:
>
> https://web.archive.org/web/20200209034547/http://aegis.sourceforge.net/auug97.pdf


+1000

In October 2001 I applied the logic of that paper to a 1/2 million line
work project to cut its build time by a factor of 20 and make it reliably
build the Right Stuff.  Took less than a month to win back the entire time
I had spent reading the paper and working out the details of the new
Makefile setup.


Philip Guenther

Re: bug report

[Philip Guenther]

On Wed, Mar 3, 2021 at 1:00 PM Goran V.  wrote:

> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> > If by "a feature like that" you mean a way to create multiple pattern
> > rules with a single rule definition in the makefile, then obviously
> > this would require some new syntax but assuming that syntax existed I
> > don't see why it would break anything.
>
> Yes, that is what I mean with "a feature like that". But I must say
> that I'm in no position to propose a patch as make is huge,
> http://git.savannah.gnu.org/cgit/make.git/tree/ .
>

This can be emulated in current GNU make via a function and a variable to
hold the commands.

To get the effect you wanted, you would define this function in one place,
before any use of it:

independent_patterns = $(foreach target, $1, $(eval ${target}: ${2};
$(value $(strip $3


Then, instead of writing what you tried:

$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js   \
$(BUILD)/$(FRONTEND)/%.css  \
$(BUILD)/$(FRONTEND)/%.svg  \
$(BUILD)/$(FRONTEND)/%.ico:
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"

You would write this:

define cmds
@echo -n "$(FRONTEND) - building $@"
@$(MD) $(BUILD)/$(FRONTEND)
@cp $(FRONTEND)/$(@F) $@
@echo " ...done"
endef
$(call independent_patterns, \
$(BUILD)/$(FRONTEND)/%.html \
$(BUILD)/$(FRONTEND)/%.js   \
$(BUILD)/$(FRONTEND)/%.css  \
$(BUILD)/$(FRONTEND)/%.svg  \
$(BUILD)/$(FRONTEND)/%.ico, , cmds)


Not the most obvious, friendly syntax, but it appears to do what you're
trying to accomplish.


Philip Guenther

Re: [PATCH] Add the --nice argument to make

[Philip Guenther]

On Mon, Sep 16, 2019 at 4:17 PM Palmer Dabbelt  wrote:

> I call make quite regularly, and I almost always want to invoke it with
> at least a bit of nice to avoid it eating my whole machine.  Since I can
> stick "-j$(nproc)" in my shell's default MAKEFLAGS I frequently end up
> being lazy and just typing "make", which I then have to kill in order to
> re-run as "nice -n10 make".
>

This sounds like a perfect case to use a shell alias or function in your
shell's rcfile, or a shell script in your person bin directory.  i.e.,
something like
alias make='nice -n10 make'
or maybe
make() { nice -n10 /usr/bin/make "$@"; }


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: lex implicit rule chain is broken

[Philip Guenther]

On Sat, May 18, 2019 at 10:30 PM Mohamed Akram 
wrote:

> Thanks for the tip. I'm not sure why it doesn't just fail immediately
> then, instead of taking a few steps and stumbling on itself.
>

In order to fail early, make would have to assume it knows more than you
do, but it's just a dumb program and you might be doing something unusual
but perfectly legal.  How can make know whether the compiler/link on your
system does something special with .l files, beyond the normal
interpretation as lex files?

Just out of curiosity, I tested the same thing with FreeBSD make
> (`LDFLAGS=-ll make`) and it compiled `lang` as expected with this output:
>

The short answer is that FreeBSD make uses '$<' in the recipe of the
applicable .c: pattern rule, while GNU make use '$^' in the parallel rule.

Note that FreeBSD make doesn't actually require the dependency: you get the
same results when the makefile is just
   lang:

Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: lex implicit rule chain is broken

[Philip Guenther]

On Sat, May 18, 2019 at 9:07 PM Mohamed Akram 
wrote:

> echo "lang: lang.l" > Makefile
>

This Makefile is incorrect, as it tells make that 'lang.l' is a *direct*
dependency of lang.  That's not true: lang.l has to be run through lex to
get a .c file that can compiled to get lang.



> It tries to link the .l file.
>

make doesn't need any special instructions to tell it how to generate an
executable from a .l file, but it'll do the Wrong Thing if you tell it the
wrong thing.  To achieve your apparent goal you can simply run it with *no*
Makefile and give it the name of the matching executable (ala "make lang"
in this case) or use a Makefile sets the default target ala
   echo ".DEFAULT_GOAL = lang" >Makefile
and it'll deduce the rest from its default pattern rules.


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #51311] Checking search retries for implicit make rules

[Philip Guenther]

On Sun, 25 Jun 2017, Mike Gran wrote:
> Follow-up Comment #1, bug #51311 (project make): You've opened this as a 
> bug. I believe it is not a bug.  Again. I'm not a maintainer.
> 
> Please note two things.
> 
> 1. while "MOTD%.log: MOTD%.txt" is a pattern rule, "MOTD%.log: MOTD%.txt
> MOTD%.in" is not a pattern rule, because it has two entries after the colon. 

This is incorrect.  To quote the make info pages, section 10.5.1
"Introduction to Pattern Rules":
-
A pattern rule contains the character `%' (exactly one of them) in the
target; otherwise, it looks exactly like an ordinary rule.  The target
is a pattern for matching file names; the `%' matches any nonempty
substring, while other characters match only themselves.  
-

There's no restriction in the documention on the number of prequisites on 
the rule and they may contain any mix of pattern and non-pattern names.  
See that page and the others in that section for further details.



> 2. The '%' (the stem) in a pattern rule doesn't, if I recall correctly, match
> a null string.  It needs to match at least a single character, so building
> MOTD.log won't work.

This is correct, as per the documentation quoted above.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking alternatives for a dynamic make rule construction

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> I have constructed the following small script to be executed by the program
> “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system.
> 
> 
> define rule_pair =
> name::=$(1)

Using ::= in a makefile which is already dependent on GNU make is, IMO, 
pointless.  If you're using $(eval) and $(call) then you should rename 
this file to GNUmakefile and just use := because it's portable across 
practically all versions of GNU make.  It's free to you annd it'll make 
developers on non-Linux systems more happy since you'll have signalled the 
GNU make requirement directly.


> $$(name:.ml=.cmo): $$(name)
>   $$(OCAMLC_CMD) -c $$<
> 
> $$(name:.ml=.cmx): $$(name)
>   $$(OCAMLOPT_CMD) -c $$<
> endef
>
> $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x
> 
> 
> I guess that the functionality from this approach is similar to the 
> usage of two specific suffix rules. But I would like to distinguish the 
> involved software dependencies better.
> 
> 
> I imagine that it would be nice to improve the shown implementation 
> details.
> 
> 1. I am using the extra variable “name” just for the reuse of the make
>functionality “substitution references”.

You can substitution references with ${1} directly, ala ${1:.ml=.cmo}


>I would prefer to append desired file name suffixes directly instead 
>of replacing a previous one. Can the passed text list become a bit 
>smaller eventually?

I *think* you're asking whether rule_pair could take just the bare 
basename (ala "commands" instead of "commands.ml").  If so, then sure: a 
substitution reference could have an empty replacement part:
${1:=.cmo}

will expand to "commands.cmo" if $1 is "commands"


> 2. The specification “$$(name)” is working. Would it make sense to avoid
>such a variable reference there? Unfortunately, the simple 
>specification “$(1)” does not work in the way I would expect for the 
>selection of a single file as a dependency. Would you like to explain 
>this software behaviour?

I started to write a long explanation of how $(eval) works but then 
realized it didn't explain when $(1) didn't work for you.

So: nope, can't explain the error message you saw, because it makes *no 
sense* to me why it didn't work based on what you wrote.

In case the theme of my replies isn't 100% clear: it would be a *lot* 
easier to assist you if you included the complete input you tried, the 
complete output you got, and *what you expected/desired*.

Or we can guess, and then give up and go away.


Philip

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking application of dependencies from make rules without recipes

[Philip Guenther]

On Fri, 16 Jun 2017, SF Markus Elfring wrote:
> I got some special software development experiences by the usage of the 
> program “GNU Make 4.2.1-1.7” on my openSUSE Tumbleweed system. The 
> functionality “Generating prerequisites automatically” is desribed in 
> the manual. I would like to check again how good this works at the 
> moment.
> 
> I am trying also a software out where such build dependencies are 
> provided by the tool “ocamldep”. Unfortunately, I observe still broken 
> build tries because of missing files which should have been built 
> before. I started to “fix” this for my needs by the addition of small 
> make functions which construct extra rules. But it seems that such 
> special stuff should usually not be needed according to the 
> documentation.
> 
> I would appreciate further advice for this issue.

Could you provide examples of the Makefiles rules you tried?  It's very 
difficult to provide feedback without complete information.  Does ocamldep 
generate output suitable for inclusion by make?  What rule did you use to 
invoke it?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > Did you tell make, then, to disable all of its default rules for 
> > creating commands.mli or, for that matter, commands.cmo, by checking 
> > them out of version control?
> 
> Not directly so far. - The source file “commands.mli” is not needed for 
> the generation of the object module “commands.cmo” in the final use 
> case.

I believe the point of Martin's rhetorical query is "why should make treat 
the failure of *this* pattern rule any different than the failure of the 
many other pattern rules that would have permitted this compilation to 
complete?"

If comands.ml,v had existed, then the make command you had invoked would 
have completed, because make would have invoked the
%:: %,v
rule and then the rule you supplied.  Alternatively, if commands.cmo,v 
have existed, then make could have used that to generate commands.cmo 
directly, so why shouldn't it say
The target “commands.cmo” could not be built because the specified
dependency “commands.cmo,v” did not exist.
?


You *looked at* the the "make -d" output and saw the long list of files 
that make considered as possible prerequisites for building command.cmo; 
if *any* of those existed then make would have been able to build the file 
and complete your request.

If you want to change the error messages that make generates, you have to 
look at that list coldly and without passion and say "is there a rule that 
improves the error output in this case?  Is that output at least as good 
for *other* makefiles?"  If the answers aren't both "yes", then you're 
suggesting a trade-off of your makefile for someone else's and have this 
consider and explain *why* their usage may be made worse to make yours 
better.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Thu, 15 Jun 2017, SF Markus Elfring wrote:
> > (I would guess that most of the people on the bug-make mailing list have 
> > never worked with ocaml and therefore don't know what needs to be done to 
> > build it.)
> 
> Yesterday I realised that one source source file needed a special handling
> in the mentioned subdirectory.
> 
> 
> > The snippet of Makefile you provided didn't include any rules for 
> > building "commands.ml", so I don't understand why you expect make to 
> > build it.
> 
> The suffix “ml” denotes a source file in this use case.
> 
> I needed another moment to become really aware that this software module
> is a bit special. It seems that it is intended that it will be compiled
> without a corresponding interface description file (suffix “mli”).

Well, I'm totally lost.  Here's why:

You told make ".cmo files can be built from *THE COMBINATION OF* the 
matching .cmi and .ml files, but *only* if both the files exist or can be 
built via some other rule".  That is what this rule says:

%.cmo: %.ml %.cmi
   $(OCAMLC_CMD) -c $<

Now you're saying that commands.cmo could be built from *just* 
commands.cmi without commands.ml!  If the real rule is that .cmo files can 
be built from .cmi files (and they _sometimes_ depend on .ml files) then 
the multi-dependency rule you used should be replaced with the single 
dependency rule:

%.cmo: %.cmi
   $(OCAMLC_CMD) -c $<

...and the additional dependency of whatever.cmo on whatever.ml should be 
expressed separately...or even automatically generated like what is done 
in modern C projects.

Indeed, do .cmo files sometimes depend on _other_ .ml files, such that 
"foo.cmo" might need to be rebuilt if "bar.ml" changes?  If so, then you 
might just have too many dependencies but all too few and should be 
looking at the direction make-for-C went to solve this.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Checking software build tries for “commands.cmo”

[Philip Guenther]

On Tue, 13 Jun 2017, SF Markus Elfring wrote:
> I am testing the following pattern rules with the program “GNU Make 4.2.1-1.7”
> on my openSUSE Tumbleweed system as I would like to adjust some areas
> in affected make scripts for another evolving software tool.
> 
> …
> %.cmi: %.mli
>   $(OCAMLC_CMD) -c $<
> 
> %.cmo: %.ml %.cmi
>   $(OCAMLC_CMD) -c $<
> 
> %.cmx: %.ml %.cmi
>   $(OCAMLOPT_CMD) -c $<
> …
> 
> I have tried a specific command out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> common.cmo V=1 
...
> This test showed the expected results.

Two questions:
1) What files were present in the directory before you ran that command?
2) What _was_ that expected result?

(I would guess that most of the people on the bug-make mailing list have 
never worked with ocaml and therefore don't know what needs to be done to 
build it.)


> I have tried another command variant out.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205/commons> LANG=C make -d 
> commands.cmo V=1
...
> Now I wonder why I do not get the desired software generation results for
> this test case. Why is the source file “commands.ml” not compiled again
> in the way as the other one?

The snippet of Makefile you provided didn't include any rules for building 
"commands.ml", so I don't understand why you expect make to build it.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Non existing target not marked as new

[Philip Guenther]

On Wed, Feb 8, 2017 at 5:48 AM, Raz Manor <raz.ma...@valens.com> wrote:
> I created a makefile using instructions for this post:
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
>
> To test it, I make all my files, then deleted one .d file and touched one of
> the header files present in that .d file.
>
> The target, however, was not rebuilt.
>
>
>
> Running with -d, I found that the empty rule to make %.d files, ran the
> first time the %.d file was needed, in the -include directive.
>
> Than the target was marked as built by make, so the second time it was
> needed, when building the .o file, the empty recipe was not re-run.
>
> However, since the .d file still didn’t exist, the .o file was not rebuilt.
>
>
>
> The author of the article was assuming that if a target is marked as built,
> all the target it's their prerequisite will also be rebuilt, regardless of
> the actual state of the target.
>
> Was he mistaken?
>
> If so, is this a bug, or the intended behavior?
>
> I this is the intended behavior, how can I achieve the same affect?

I started to try to guess at the problem, but that's a waste of time
when you could just copy your test Makefile in to email to the list.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: exported vs command line variables

[Philip Guenther]

On Fri, Sep 23, 2016 at 4:09 PM, David Boyce <david.s.bo...@gmail.com> wrote:
> In that case there does seem to be at least one bug here. In reference to
> the sentence:
>
> "Macros defined by the MAKEFLAGS environment variable and macros defined in
> the makefile(s) shall not be added to the environment of make if they are
> not already in its environment."
>
> And building on Eddy Welbourne's example:
>
> % cat Makefile
> WURGLE = 11
> MAKEFLAGS = WURGLE=$(WURGLE)

You need to read all the applicable bits in the standard before
calling behavior incorrect.  In particular, the Macros section has
this line earlier in it:
The result of setting MAKEFLAGS in the Makefile is unspecified.

So if you want POSIX-like behavior, don't do that; if you do that,
you're at the whims of GNU make's choices.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: exported vs command line variables

[Philip Guenther]

On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith <psm...@gnu.org> wrote:
> On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote:
>> I still think that's a good plan, except that now I find out it ends
>> up exporting anyway. I'm sure it's too late to change now but is
>> there a reason for this (unfortunate IMHO) behavior?
>
> I can't tell you: this behavior has existed since the very first import
> of GNU make code into source code control, back in 1991.

...and in System III in 1980:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/make

Looks like BSD picked it up in 4.4 around 1993 with the switch to pmake:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/make


POSIX specifies this behavior in the "Macros" subsection of the
EXTENDED DESCRIPTION section for 'make'.  About a page and half in is
this paragraph:
Before the makefile(s) are read, all of the make utility command
line macro definitions (except the
MAKEFLAGS macro or the SHELL macro) shall be added to the
environment of make. Other
+   implementation-defined variables may also be added to the
environment of make. Macros
+  defined by the MAKEFLAGS environment variable and macros defined in
the makefile(s) shall
+   not be added to the environment of make if they are not already in
its environment. With the
+   exception of SHELL (see below), it is unspecified whether macros
defined in these ways update
the value of an environment variable that already exists in the
environment of make.

(That's from the 2013 draft update; the '+' lines were modified from
the original 2008 version of the standard, but that doesn't affect the
first sentence.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #49093] ifdef checks for non-empty value, not definition

[Philip Guenther]

On Wed, Sep 14, 2016 at 3:13 PM, Paul D. Smith  wrote:
...
> Probably an example like this would help make the doc more clear.

There *is* an example like that in the doc in at least version 4.2.1!

 Note that `ifdef' only tests whether a variable has a value.  It
 does not expand the variable to see if that value is nonempty.
 Consequently, tests using `ifdef' return true for all definitions
 except those like `foo ='.  To test for an empty value, use
 `ifeq ($(foo),)'.  For example,

  bar =
  foo = $(bar)
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `yes', while:

  foo =
  ifdef foo
  frobozz = yes
  else
  frobozz = no
  endif

 sets `frobozz' to `no'.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Difficulties from the combination of functions call and eval

[Philip Guenther]

To home in on one key point here...


On Sun, Jan 18, 2015 at 4:31 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
...
 Lines 183 - 203:
 define RESULT_CHECK
 for part in $(1); do \
 if test x$$( $$part) != x0; then \
 $(PRINTF) $$(TEXT3) '$$part'; \
 exit 12; \
 fi; \
 done \
  $$(TOUCH) '$(2)'
 endef

 That looks like it expands to shell text when used with $(call), so
 just call it in a recipe!

 Yes. - The evaluated variable should produce shell commands for recipes.
 I try to reuse it as a subfunction.

You use the word evaluated there, which I think reflects an
incorrect view of make's operation. To define the words as they're
used in the make documentation:

-  make _expands_ variables and functions, as marked with a leading
dollar-sign.  This
-  make _executes_ recipes and the argument of the $(shell) function
by passing the _expanded_ text to the shell
-  make _evaluates_ the its own input, the makefile, files that it
includes, the argument of the --eval CLI option, and the _expanded_
argument to the $(eval) function

You do not need $(eval) to get expansion to do its job of creating the
final string to pass to the shell in a recipe, for example.

define STUFF
# some shell commands here
sort inputs | uniq -c outputs
endef

define MORESTUFF
# do something, then do STUFF
create_inputs inputs
${STUFF}
endef

all:
${MORESTUFF}

When 'all' is built, ${MORESTUFF} will be expanded (which will involve
expanding the ${STUFF} inside it) to get a final string, which will
then be passed to the shell.  No need for ${STUFF} or ${MORESTUFF} to
explicitly say execute this or evaluate this.

That's true even when you use $(call):

# Generate file $2 from file $1
define STUFF
# some shell commands here
sort $1 | uniq -c $2
endef

# Generate $1
define MORESTUFF
# do something, then do STUFF
create_inputs inputs
$(call STUFF,inputs,$1)
endef

all:
$(call MORESTUFF,output)

When building 'all', make will expand $(call MORESTUFF,output) by
temporarily setting $1 to 'output' then expanding MORESTUFF.  The
$(call STUFF,inputs,$1) inside that will temporarily override that by
setting $1 to 'inputs' and $2 to 'output' then expanding STUFF.  The
result will be the same as the earlier example.


That distinction between expansion, execution and evaluation make sense?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Questionable line number in a message missing separator?

[Philip Guenther]

On Sat, Jan 17, 2015 at 12:52 PM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 Of course, if you had actually quoted the relevant lines from your
 Makefile, we could be more precise.

 Thanks for your interest.

 Do you get further ideas from an excerpt of my build script 
 parallel-inc.make?

 Lines 241 - 256:
 $(EXIT_CODES_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS) \
 $(RESULT_SQL_DATABASE_NOTIFICATION3) \
 $(RUN_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS): \
 initialise_database \
 $(BUILD_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS) \
 $(HEADER_SEARCH_PARTS)
 $(if 
 $(LET_RUN_FIND_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS_PARALLEL),\
 $(eval 
 LET_RUN_FIND_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS_PARALLEL::=)$(eval
  $(call HANDLE_BACKGROUND_TASK,\
 $(RESULT_SQL_DATABASE_NOTIFICATION3),\
 $(RUN_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS),\
 $(BUILD_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS),\
 $(EXIT_CODES_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER_IN_HEADERS

 find_functions_that_check_their_single_parameter_in_headers_with_parallel_groups:
  \
 $(RESULT_SQL_DATABASE_NOTIFICATION3)
 @$(ECHO) 'Header files were analysed.'

wipes tears from eyes

So that $(eval $(call GIBBERISH)) is wrong.  Exactly *how* it's wrong
depends on what the $(call) is supposed to return.  Currently you're
evaling something that doesn't look like a *STANDALONE* chunk of
Makefile, which results in the error *in the eval*.


Paul, I still think $(eval) should have been named
$(stick-arm-in-woodchipper), to make it less seductive to people
trying to layer imperative programming on the declarative nature of
make.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Questionable line number in a message missing separator?

[Philip Guenther]

On Sat, Jan 17, 2015 at 11:06 AM, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
 But the software tool make 4.1-2.2 does not like
 a specific place in this file at the moment.

 …
 parallel-inc.make:247: *** missing separator.  Stop.


 The mentioned line has got a leading tab character
 for the beginning of a recipe.
 How can this syntax difficulty be resolved now?

A line starting with a tab is only interpreted as part of a recipe if
the previous non-comment line was either a rule or another recipe
line.  If the previous line was an include, a variable assignment, a
vpath setting, etc then the previous recipe is closed and you can't
add another recipe line to it.

Of course, if you had actually quoted the relevant lines from your
Makefile, we could be more precise.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: bug with order-only prerequisites implicit rules implementation ?

[Philip Guenther]

On Sat, Jan 10, 2015 at 7:06 PM, Jason Vas Dias
jason.vas.d...@gmail.com wrote:
 Please could anyone explain the behaviour of this test makefile (attached) :

 quotecode
 TMP:=/tmp

 %.ext:
 touch $@

 .PHONY: *.oop
 %.oop:
 @echo 'A phony order-only prequisite of /tmp/a.t';

 #$(TMP)/%.t: | %.oop

 $(TMP)/%.t:$(TMP)/%.ext | %.oop
 @echo Specific Rule

 %.t:%.ext
 @echo General rule

 /code/quote

 when invoked with :

   $ make -f ${the_makefile} /tmp/a.t

 I would expect that the most specific matching first rule
 would be invoked always, with its extra order-only
 pre-requisite recipe always being invoked, but actually
 this occurs only if /tmp/a.ext does not already exist -
 I tested latest make-4.1, and make-3.82, on a RHEL6 linux
 platform,  and both show the same behaviour:

 $ make -f ${the_makefile} /tmp/a.t
 touch /tmp/a.ext
 A phony order-only prequisite of /tmp/a.t
 Specific Rule
 rm /tmp/a.ext

 but if I :
 $ touch /tmp/a.ext
 and then :
 $ make -f ${the_makefile} /tmp/a.t
 Gemeral Rule

This behavior is documented.  To quote from the info pages, section
10.5.4 How Patterns Match:

   A pattern rule can be used to build a given file only if there is a
target pattern that matches the file name, _and_ all prerequisites in
that rule either exist or can be built.  The rules you write take
precedence over those that are built in. Note however, that a rule
whose prerequisites actually exist or are mentioned always takes
priority over a rule with prerequisites that must be made by chaining
other implicit rules.


When /tmp/a.ext exists but a.oop doesn't, then the 'general' rule has
precedence because all the prerequisites exist, while the 'specific'
rule has a non-existent prerequisite (a.oop).


 If I remove the phony order only dependency. so that the /tmp/%.t rule reads:
 quotecode
 $(TMP)/%.t:$(TMP)/%.ext
 /code/quote
 then the makefile always runs the first recipe, regardless of the existence
 of /tmp/a.ext :

Given the explanation above, that should make sense.



 Also, a second problem is that order-only dependencies are not
 recognized when specified by multiple rules without recipes are
 specified  for same target , ie:
 quotecode
 $(TMP)/%.t: | %.oop
 $(TMP)/%.t:$(TMP)/%.ext
 /quote/code
 has the same effect (recipe for implicit order-only pre-requisite never runs)
 as no order-only dependency being specified at all. I thought the
 dependencies should be merged and the %.oop recipe should be run in
 this case, especially as I've told make that all *.oop targets are
 phony.

Pattern rules, unlike normal rules, are never merged.  Each one stands
alone and either completely overrides a previous pattern rule with the
exact same target and prerequisites (but possibly different commands,
or *no* commands, which cancels the previous pattern rule), or adds a
new pattern for the target with different prerequisites.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #42690] make unconditionally resolves the current directory

[Philip Guenther]

On Sat, Jul 5, 2014 at 12:57 PM, anonymous invalid.nore...@gnu.org wrote:

 { cd /tmp  mkdir a  ln -sT a b  cd b  make -w; }

 make: Entering directory `/tmp/a'

 Why not /tmp/b?  Is there an option to prevent this resolution?
 I understand that relative path names must be resolved;
 but could you leave directory aliases as they are please?


The best make would be able to do would be to model its behavior on that of
pwd -L: if the PWD environment variable is set to an absolute path with
no .. or . components that resolves to the process's current directory,
then use that instead of the path from getcwd().


This hit me when I tried to make in a directory that had a colon in the
 name;


Doctor says: Don't do that!   make is only one of many program which you
will have problems with.


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Question about pattern rule with multiple targets

[Philip Guenther]

On Fri, Jun 27, 2014 at 11:24 AM, Tom Varga tomva...@gmail.com wrote:

 On page 120 of the gnumake manual, it mentions support for pattern
 rules with multiple targets.

 This pattern rule has two targets:
 %.tab.c %.tab.h: %.y
  bison -d $

 So, if I have a simple rule that looks like:

 %.bar1 %.bar2 : %.foo
 touch $(*F).bar1
  touch $(*F).bar2

 and then do:

  touch a.foo
  make a.bar1
 touch a.bar1
 touch a.bar2
  make a.bar1
 make: 'a.bar1' is up to date.
  rm a.bar2
  make a.bar1
 make: 'a.bar1' is up to date.
  make a.bar2
 touch a.bar1
 touch a.bar2

 What I was really hoping is that make would consider both a.bar1 and
 a.bar2 to be required outputs of the rule and if one of them is
 deleted, then both the .bar1 and .bar2 targets should be considered
 out-of-date.  But when I manually remove the a.bar2 file, the a.bar1
 file is still considered to be up-to-date.  Yet, when I then ask to
 build the a.bar2 target, both the a.bar1 and a.bar2 targets are
 re-built.


Umm, why isn't this solved by having a correct dependency on a.bar2 where
necessary?


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Question about pattern rule with multiple targets

[Philip Guenther]

On Fri, Jun 27, 2014 at 2:52 PM, Tom Varga tomva...@gmail.com wrote:

 b.zoo1 really only depends on b.bar1
 b.zoo2 really only depends on b.bar2

 However, only one rule (and tool) is used to build both b.bar1 and b.bar2

 I really don't want force b.zoo1 to artificially depend on b.bar2 as it's
 not a real dependency.

 I was really just hoping to be able to convince gnumake that b.bar1 and
 b.bar2 are built with the same rule


It works just fine for that!



 and MUST be consistent, that is both having been built at the same time
 and that both exist too.


Ah, *this* is the issue, the fact that you can't use generated files from
different runs.  For most(?) program that generate multiple files, mixing
and matching isn't an issue when the source file is unchanged.  If the
source file is changed, then make's current bits handle it just fine,
rebuilding both, of course.

There's certainly some way to express the if the either file is missing,
rebuild both using $(if) and $(wildcard) to check for existence, but my
reaction right now is fix the tool that isn't generating consistent
output...


Philip Guenther
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: error reporting

[Philip Guenther]

On Mon, Apr 7, 2014 at 4:45 PM, Rob Juergens rjuerg...@esri.com wrote:
 Given the make file (makefile):

 --
 foo : bar
 --

 gmake 3.75 gives this:

 gmake: *** No rule to make target 'bar', needed by 'foo'. Stop.

 gmake 4.0 gives this:

 gmake: ***. stop.

 This has caused a lot of time trying to figure out what is wrong with the
 makefile. A big step backward in error reporting.

 Please fix this.

I am unable to reproduce this:

: morgaine; ls -l
total 2
-rw-rw-r--  1 guenther  wheel  10 Apr  7 21:22 Makefile
: morgaine; cat Makefile
foo : bar
: morgaine; gmake --version
GNU Make 4.0
Built for x86_64-unknown-openbsd5.5
Copyright (C) 1988-2013 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.
: morgaine; gmake
gmake: *** No rule to make target 'bar', needed by 'foo'.  Stop.
: morgaine;


What information about your situation did you leave out?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: vms:test variables

[Philip Guenther]

On Thu, Apr 3, 2014 at 9:56 PM, John E. Malmberg wb8...@qsl.net wrote:
 This is the patches for the variables tests on VMS.

I'm kinda surprised that you haven't worked out some direct
coordination with the GNU make developers for the handling of these
diffs.  I don't see how sending them to the full bug-make list is
useful; are you expecting random list members to provide feedback on
them?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

On Tue, 28 Jan 2014, Mark Brown wrote:
 On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown mkbrown_...@hotmail.com wrote:
From: Paul Smith
Sent: Monday, January 27, 2014 8:57 PM
  ...
 ifneq ($(filter else-if,$(.FEATURES)),else-if)
   $(error Version $(MAKE_VERSION) does not support else-if)
 endif
   Are you saying that this statement can be placed outside
   of a make target recipe command sequence,
   and would be executed before the target recipe command sequence ?
  The answer to your question can be found in the GNU make info pages.
  Or, you could just TRY IT AND GET THE ANSWER INSTANTLY.
 This is what the new make 4.0 manual says about -trace capability:

So, you're _not_ going to just try the ifneq()...endif example that Paul 
provided?  Gotcha.


 =
 ?--trace? Show tracing information for make execution. Prints the entire
 recipe to be
 executed, even for recipes that are normally silent (due to .SILENT or ?@?).
 Also prints the makefile name and line number where the recipe was defined,
 and information on why the target is being rebuilt.
 =
 
 Again, this is a re-paste of the desired output,
 which again you deleted in your reply:

No, it doesn't provide output in that format.  Your suggested output 
format can't be unambiguously parsed when the variables contain 
whitespace, which would make the output much less useful.


...
 Your role is maintenance of the make project.

I'm sorry, but you appear to suffer misconceptions about the project and 
myself.

I have *NO* official role in the project.  I'm just someone that uses it 
and answers some questions on the list.


 It is not your role to solve other people's engineering problems.

Huh.  What gave you the role of deciding what other peoples' roles are?


 When a bug or omission is presented to you, you have
 at least 3 appropriate response options:
 1) we do not think that is an issue that needs to be solved by make,
 2) that issue needs to be solved in make, and it is, but in a different way
 from what may be apparent from the documentation or intuitive,
 Read the following link URL, chapter, section etc.
 3) we do think that issue should solved by make, but it has
 yet to be implemented.

HAHAHHAHAHAHHHAHAHAHAHA

Do you have a contract with me or, for that matter, with the GNU make 
project which would let you specify that?  Heck, do you get to specify 
that when you complain to Microsoft about bugs in their tools?


(There are plenty of courteous people that ask questions on this list.  I 
shouldn't stop giving my minimal help in answering their questions just 
because one person stomps in complaining that we must answer questions in 
the way he demands.)



Philip

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown mkbrown_...@hotmail.com wrote:
 First, let me request that you include the question posed to you,
 in your Reply responses in this email sequence.

How about you stop top-posting and instead reply inline?


 1)  I think my question was explicit.
 A method for an existing Makefile to test for .FEATURES capabilities
 when it is downloaded to a random linux or Windows make environment
 and existed.

sigh That wasn't the question you originally asked.  To quote your
original query about .FEATURES:

 As a separate related issue,
 I was try to echo the .FEATURES information, since one of the its it claims 
 to display
 mentions its Else If capabilities.
 However, every time I tried to echo the data I received a syntax error.
 What would be an example of a Makefile contents which would display
 the .FEATURES information ?

The example that Paul gave answers that original question:
all:
echo ${.FEATURES}


So now you have a new question

 The Makefile itself when e.g make target is selected, should be
 able to precede execution of any target with a check of .FEATURES
 to verify the make environment into which it is downloaded.
 Give an example of .FEATURES display/echo in an existing Makefile.,
 both v 3.80 and 4.00 .






 2)  Also, please answer the other question posed:
 ---

 I also want to know if there is a debug mode within make
 in which the Makefile filename and Line Number
 (some Makefiles are huge and distributed over several subordinate Makefiles)
 is matched to each automatic variable evaluation within a Target evaluation.
 ---

 If either of these make capabilities are not possible currently,
 then that is a case for implementation in  Make  version 4.1 .




 -Original Message- From: Paul Smith
 Sent: Monday, January 27, 2014 9:35 AM
 To: Mark Brown
 Cc: bug-make@gnu.org

 Subject: Re: win32 compilation of make 4.0 source code

 On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote:

 That example method is a device to perform this .FEATURES test
 without inserting it into an existing Makefile.
 The syntax errors I was seeing were occurring when attempting to insert
 this
 test into an existing Makefile, full of Targets and command sequences.


 Well, since you've provided no details about exactly what you tried and
 what errors you received, or even details about exactly what you're

 trying to do, there's not much else we can say.  You said echo the
 data, and I showed an example of echoing the data.  If that's not what
 you want, you need to give more information.

 
 ==re-pasted text of the question posed=
 

 That example method is a device to perform this .FEATURES test
 without inserting it into an existing Makefile.
 The syntax errors I was seeing were occurring when attempting to insert this
 test
 into an existing Makefile, full of Targets and command sequences.
 If this feature is used it would be at the top of an existing Makefile,
 before any targets
 are evaluated.

 I also want to know if there is a debug mode within make
 in which the Makefile filename and Line Number
 (some Makefiles are huge and distributed over several subordinate Makefiles)
 is matched to each automatic variable evaluation within a Target evaluation.
 =



 ___
 Bug-make mailing list
 Bug-make@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: win32 compilation of make 4.0 source code

[Philip Guenther]

(Dang it: gmail treats control-enter as send...)

On Mon, Jan 27, 2014 at 1:12 PM, Philip Guenther guent...@gmail.com wrote:
 On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown mkbrown_...@hotmail.com wrote:
 First, let me request that you include the question posed to you,
 in your Reply responses in this email sequence.

 How about you stop top-posting and instead reply inline?


 1)  I think my question was explicit.
 A method for an existing Makefile to test for .FEATURES capabilities
 when it is downloaded to a random linux or Windows make environment
 and existed.

 sigh That wasn't the question you originally asked.  To quote your
 original query about .FEATURES:

 As a separate related issue,
 I was try to echo the .FEATURES information, since one of the its it claims 
 to display
 mentions its Else If capabilities.
 However, every time I tried to echo the data I received a syntax error.
 What would be an example of a Makefile contents which would display
 the .FEATURES information ?

 The example that Paul gave answers that original question:
 all:
 echo ${.FEATURES}


 So now you have a new question

 The Makefile itself when e.g make target is selected, should be
 able to precede execution of any target with a check of .FEATURES
 to verify the make environment into which it is downloaded.
 Give an example of .FEATURES display/echo in an existing Makefile.,
 both v 3.80 and 4.00 .

This is where Paul question of what did you already try? comes in.
Rather than give you a fish, it would be better to teach you how to
fish; seeing what you tried would let us correct whatever
misunderstanding caused the syntax errors you got.

Or you could search the archives for examples, if you really don't
want to understand.


 2)  Also, please answer the other question posed:

Hmm, how much are you paying for these answers?  Oh right, nothing...


 ---

 I also want to know if there is a debug mode within make
 in which the Makefile filename and Line Number
 (some Makefiles are huge and distributed over several subordinate Makefiles)
 is matched to each automatic variable evaluation within a Target evaluation.
 ---

Since you don't say what debug output you've already looked at, I'll
just suggest two possibilities
1) make -pq and examine the dumped output, which gives file and line
number for all commands
2) check out the remake project. http://bashdb.sourceforge.net/remake/


 If either of these make capabilities are not possible currently,
 then that is a case for implementation in  Make  version 4.1 .

You didn't describe the problem that you're trying to solve; how do
you know that data would solve it?  Why *only* automatic variables?
If there are several levels of variable expansion involved, what
should the output look like?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make doesn't complain if target cannot be built

[Philip Guenther]

On Mon, Jan 13, 2014 at 9:56 PM, Christian Eggers cegg...@gmx.de wrote:
 Is there a workaround for this? Using explicit rules seems to be difficult in
 my case because some objects are built from .c sources, other from .cpp.
 Is there a better way instead of this:

 SOURCES_C := foo.c
 SOURCES_CPP := bar.cpp
 SOURCES_ASM := ...

 OBJS := $(SOURCES_C:%.c=%.o) $(SOURCES_CPP:%.cpp=%.o) ...

 $(SOURCES_C:%.c=%.o):
 $(COMPILE.c) ...

 $(SOURCES_CPP:%.cpp=%.o):
 $(COMPILE.cpp) ...

 $(OBJS): generated.h

 EOF

In many cases, I've found it completely unnecessary to list the source
files.  Just list the objects that should be built and provide pattern
rules for the source types, then let make figure out which source
files generate which objects from the patterns, ala:

OBJS = foo.o bar.o ...
%.o: %.c:
$(COMPILE.c) 
%.o: %.cpp
$(COMPILE.cpp) 
...
$(OBJS): generated.h


You only need to match sources to objects if there's a naming
conflict...which I would tend to solve by renaming the file that
doesn't belong.


Side point: you only list an explicit dependency for a file named
generated.h, which suggests you're using some sort of automated
dependency technique (gcc -MD, make depend, etc) for handling
dependency tracking for other .h files.  If that's the case, then it
can be slightly better to use an order-only prerequisite for the
generated file, ala:

$(OBJS): | generated.h

That guarantees the generated.h file will exist before trying to build
any objects, but if generated.h gets rebuilt, only the objects that
have real dependencies from the automated dependency tracking setup
will get rebuilt.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly

[Philip Guenther]

On Thu, Oct 24, 2013 at 3:43 PM, Frank Heckenbach
invalid.nore...@gnu.org wrote:
 Another thing that changed in the course of the output patches is that
 messages are now generated in vfmtconcat() using vsnprintf() as well as
 va_copy(), both C99 and at least the latter AFAIK not very widely used.

 For testing you could try replacing the body of vfmtconcat() with vprintf
 (fmt, args);. (Keep the return statement to avoid a compiler warning; the
 returned value isn't actually used.) This will break output-sync, of course,
 but if the messages are correct then, we've found the culprits.

I no longer have notes about what version I saw it in, but HP-UX's
vsnprintf/snprintf would, when the buffer wasn't large enough, return
-1 instead of the number of chars that would have been written.

I think it also flubbed handling of buflen==0 as the workaround code
we used would make a first try passing a buflen of 1 and a single char
buf instead of a buflen of zero and NULL.  Or maybe that part was a
bug in AIX.  Hmm...


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #40056] make should automatically detect targets with low resolution timestamps

[Philip Guenther]

On Tue, Sep 17, 2013 at 10:12 PM, James Ralston invalid.nore...@gnu.org wrote:
...
 The statfs(2) system call will return the f_type field in the struct statfs,
 but unfortunately, the field is the same for all variants of ext (ext2, ext3,
 ext4). So as far as I know (although I would be happy to be corrected), there
 is no library or system call that will reveal whether the filesystem that an
 arbitrary file is on supports high resolution timestamps.

You're looking for
pathconf(path, _PC_TIMESTAMP_RESOLUTION)

See also:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html

However, last I checked glibc and Linux didn't implement it.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

[Philip Guenther]

On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy tnmur...@gmail.com wrote:
 cc fred.c -c -o fred.o
 cc bob.c -c -o bob.o
 error on line 20 -X
 error on line 30 -
 error on line 330 -
 makefile:342: recipe for target 'fred.o' failed
 makefile:350: recipe for target 'bob.o' failed

 ?

Doctor, my hammer has a head so large that I always hit my thumb
Throw out that hammer and get a non-broken one

The GNU tool working around the brokenness of some non-free software?
Some would call that collaboration in retaining your chains.

:-/



I haven't had a chance to play with the new functionality in the
repository, so I'll merely caution that having major new functionality
that will affect the user experience be on by default runs the risk of
there being a problem and having the new version be
tarred-and-feathered, and the projects that would most benefit from
the new functionality instead turning it off.  If there are other
fixes and/or features in this release that people are waiting for,
burning them on this would be unfriendly.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38420] $(realpath ...) doesn't recover from signals

[Philip Guenther]

On Wed, Feb 27, 2013 at 9:44 AM, Brian Vandenberg
invalid.nore...@gnu.org wrote:
 Follow-up Comment #3, bug #38420 (project make):
   You're spot on.  It is Solaris / NFS 3.

   In the interim I'm using a build with the fix I suggested.

   Do you know of a workaround for this that wouldn't require deploying a
 modified version of make?

Doesn't this problem only occur if the NFS mount has the 'intr' flag?

(The intr flag basically means violate the historical UNIX behavior
because I don't trust my NFS server to recover quickly and reliably
and need a way to bail out, regardless of the consequences...)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38433] Example for eval in documentation contains error with define

[Philip Guenther]

On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar
invalid.nore...@gnu.org wrote:
 The example for the eval function in the documentation at
 http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains
 a syntax error that causes the example to fail quietly. The problem is in the
 line

  define PROGRAM_template =

 This line should not have = at the end.

No, that line is perfectly correct.  The problem is that you're still
running version 3.81, which was obsoleted almost 3 years ago.  Upgrade
to 3.82.   Or use info make to read the documentation that's
installed on your system and therefore matches the version you're
running.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38433] Example for eval in documentation contains error with define

[Philip Guenther]

On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar d...@caltech.edu wrote:
 I appreciate your correction, but I still feel that the documentation on the
 website would be more helpful if it at least mentioned that older versions
 of make fail quietly when there is a = at the end of the line. The reason
 is that make v. 3.81 is still in very wide use. For instance, it is part of
 Ubuntu 12.04-LTS as well as Mint 14.

That sounds like a bug in Ubuntu.  Or maybe it's just a consequence of
the choice of selecting a Long Term Support release.

Meanwhile, other people complain that the docs are too long; adding
this feature was added in 3.8x throughout the guide just makes it
longer and harder to read.  It's not a costless addition.

The documentation for the program on your box is on your box. WTP?


Philip

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38433] Example for eval in documentation contains error with define

[Philip Guenther]

On Wed, Feb 27, 2013 at 2:42 PM, Sebastian Pipping
invalid.nore...@gnu.org wrote:
 Paul and Philipp,

Side note: I should make clear that I am not committer to GNU make and
do not speak for the project.  I'm just a contributer to the lists,
answering questions where I can.


 Daniel has a valid point here.  You could be a lot more welcoming on this
 case, why so hard on him?  I hit the very same thing myself some time ago,
 just forgot to speak up myself.  That documentation bug is the reason meta
 programming in GNU make took my too starts, rather than one.

IMO, the suggestion that was proposed would reduce the overall
usability of the manual and increase the confusion.  I seen it tried
in multiple ways** in other open source projects (and at my day job)
and the results were never complete (there were nuances left out),
took a large amount of effort, and always made a small set of people
happy and a much larger set of people unhappy.

I'll note that glibc, which has a much larger development group
including commercial funding for several, doesn't describe when
something was added or changed in its manual.  gcc's manual only
mentions inter-version changes for the -fabi-version option (whose
whole purpose is inter-version support) and for a single specific
removed feature, with no comment when describing the multiple new
options and extensions.

(Did the manual to your car or bike or computer include comments
throughout it describing how this year's model is different from the
previous years?)

If you have an example of a manual that does that and does it *well*,
without compromising readability, I would be glad to be wrong and
interested it seeing it so that I can see how they pulled it off.


If the GNU website were to require you to select the version of make
you wanted to see the documentation for, I think that would be a
reasonable 'solution'.  Perhaps a layout like
http://gcc.gnu.org/onlinedocs/ could be done without too much
complexity.


 While I appreciate progress in GNU make, version 3.82 has produced costs over
 3.81 to many parities, see the list of bugs related to 3.82-caused breakage in
 Gentoo Linux alone: https://bugs.gentoo.org/show_bug.cgi?id=331977.

That was 2 years ago.  When does it end?  When the last Linux
distributor's Long Term Support version is off it?  They get to choose
how long that cost is imposed on this project?


 To summarize: people need all the support with the transition and with
 understanding the differences betwen 3.81 and 3.82 they can get.

That information is provided in the form of the NEWS file.  Perhaps
those should be more easily obtainable via the website, but spreading
it throughout the manual is not, IMNSHO, a solution.


  Daniel could have prepared a patch for the docs by now and be motivated to 
 do more later,
 if you had instructed him about it.  The good part about it: you may have a
 second chance.  Don't let it pass.

Or you could try doing that yourself.  No one needs my approval to do
it, or to put it on Daniel, and Paul could easily decide that your
patch is an improvement and check it in.

(Oops, guess I screwed up my second chance.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #38437] cannot find the include file

[Philip Guenther]

On Wed, Feb 27, 2013 at 8:55 PM, Jian invalid.nore...@gnu.org wrote:
...
 Supposing 2 makefiles in dir A: 1.mak, 2.mak, and 1.mak include 2.mak.
 Now in dir B, 3.mak includes 'A/1.mak' (will auto include 2.mak). But error
 shows that 2.mak cannot be found.

 The make option -I can be the workaround like:
  cd B
  make -f 3.mak -IA

 But it's not acceptable to tell user to uses -I to make every time. make
 shall be able to find 2.mak.

So have 1.mak look for 2.mak in the same directory, by doing something like:

# Get the directory part of the path by which 1.mak was included
# This should be before any other includes in 1.mak
dir_of_1 = $(dir $(lastword $(MAKEFILE_LIST)))

...and then later:

# pull in 2.mak in the same directory as this file
include ${dir_of_1}2.mak


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: prerequisites alter choice of pattern match rules?

[Philip Guenther]

On Mon, Feb 25, 2013 at 2:30 PM, Sebastian Pipping
sebast...@pipping.org wrote:
...
 It seems like normally GNU make walks the path of the most specific
 match in case of ambiguities.  I wonder if that's specified/documented
 anywhere.

Yes, it is.  I don't remember where, but it's in the docs.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: prerequisites alter choice of pattern match rules?

[Philip Guenther]

On Mon, Feb 25, 2013 at 5:57 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:
 I would think that given the following set of rules:

 /tmp/%.foo: %.foo
 echo foo rule 1
 touch $@

 %.foo:
 echo foo rule 2
 touch $@

 /tmp/%.bar:
 make $*.bar
 echo bar rule 1
 touch $@

 %.bar:
 echo bar rule 2
 touch $@

 Trying to create a target of /tmp/a.foo and /tmp/a.bar should result in
 the same rules being run but they don't:
...
 It would seem that for the /tmp/a.foo, the /tmp/%.foo pattern rule is
 not being chosen but for /tmp/a.bar the /tmp/%.bar pattern rule is
 being chosen.  The only difference in those choices I can see is that
 the /tmp/%.foo pattern rule has a prerequisite and the /tmp/%.bar
 one doesn't.

 So the question is, why does a prerequisite change the behavior of
 pattern match rules?  I would think the selection of a pattern match
 rule would be independent of prerequisites but of course once the
 pattern match rule was chosen, the rule for the prerequisite would also
 need to be called to ensure it's freshness.

 Thoughts?

When there's no explicit rule for a target (i.e., a rule where the
exact target name is listed), the algorithm for chosing the implicit
rule to apply first checks for rule(s) for which all the prerequisites
either already exist or are explicitly listed as targets themselves,
or have no prerequisites**.  Only if all the pattern rules have at
least one non-existent prerequisite that isn't explicitly listed
elsewhere does make then recursively try chaining to other rules for
each of the (missing) prerequisites.  Yes, this behavior is documented
in the info pages in more than sufficient detail to be sure that it
was clearly intended.

You ask why that's done.  To really answer that question I think you
would have to find and review the discussions among the developers
when it was actually added to GNU make, presumably back when Roland
was the maintainer.  The answer might be because that's how Stu
Feldman's version of make did it.  Or maybe it was too slow if we
tried all the possible chains, and we also wanted some way other than
order-in-the-makefile to prefer a rule.  Or if there's a direct way
to build something, it must obviously be the right choice over
something which requires an intermediate file; if you don't want that,
then you should craft your patterns and filename choices so that you
don't get overlapping patterns!

...but I wasn't there and those are just guesses.


Philip Guenther


** if there are no prerequisites, then all of the prereqs are present;
the list of missing prereqs is empty.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: timestamp bug when files are created just before make is run

[Philip Guenther]

On Thu, Dec 6, 2012 at 2:02 PM, Mikulas Patocka
miku...@artax.karlin.mff.cuni.cz wrote:
 The apparent problem is that after make rebuilds b, it compares b's time
 with a's time, finds that the times are equal (because a was touched just
 before make was run) and doesn't rebuild a.

 I think it is a bug - when b is finished, make should find out whether the
 rule for b modified the file b (if b's time is greater or equal than the
 time when the rule for b was started, then b may have been modified) and
 rebuild a in this case.

That's not the rule that make has always followed and, indeed, is
required by the standard to follow.  To quote POSIX:

The make utility attempts to perform the actions required to ensure
that the specified targets are up-to-date. A target is considered
out-of-date if it is older than any of its prerequisites or if
it does not
exist. The make utility shall treat all prerequisites as targets
themselves and recursively ensure that they are up-to-date, processing
them in the order in which they appear in the rule. The make utility
shall use the modification times of files to determine whether the
corresponding targets are out-of-date.

The fact that the timestamp on a prerequisite has changed do *not*
mean that it's newer than the target; it may have been copied from
some other file which, while newer, is still older than the target
file.  So the change to the make algorithm described in the paragraph
above that starts I think it is a bug would not be correct;
something more precise about what timestamps would be considered
newer would be necessary.


Note that this problem doesn't arise on systems with high precision
file timestamps.  Many systems have provided those since the mid 90's;
I'm appalled that the modern system that process the involved shell
commands fast enough for this to regularly be a problem don't provide
microsecond or better timestamp precision.


 This bug is causing real-world problems in automake-generated Makefiles.
 This is a simplified piece of Makefile from automake:
 all : config.h
 $(MAKE) all-am

 config.h : stamp-h1
 echo build config.h

 stamp-h1 : config.h.in
 echo build stamp-h1
 rm -f stamp-h1
 touch config.h
 touch stamp-h1

 config.h.in : am__configure_deps
 echo build config.h.in
 rm -f stamp-h1
 touch config.h.in

 all-am :
 echo ALL-AM

 Now, if you run this script, you trigger the bug:

 touch config.h.in;sleep 1;touch am__configure_deps;sleep 1;touch config.h 
 stamp-h1;make

 - you see build config.h.in, but the other files are not rebuild and
 all-am is executed
 (the essential thing to trigger the bug is that make is run in the same
 second in which config.h and stamp-h1 were created)
...
 Another possible solution for this bug would be to remove rm -f stamp-h1
 from config.h.in rule, but there is some complex explanation in
 /usr/local/share/automake-1.12/am/remake-hdr.am why rm -f stamp-h1 is
 there so it would likely fix one bug and trigger another one.

Hmm, adding a sleep 1 after that rm -f and before the touch
config.h.in would work without reintroducing the issue described in
that explanation, no?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Possible bug (documentation or make itself) not sure

[Philip Guenther]

On Tue, Nov 6, 2012 at 4:02 PM, LANGLOIS Olivier PIS -EXT
olivier.pis.langl...@transport.alstom.com wrote:
 In section 6.11:

 Target-specific variable assignments can be prefixed with any or all of the 
 special keywords export, override, or private; these apply their normal 
 behavior to this instance of the variable only.

 the way I read it is that you can specify one or many special keywords. If I 
 try to use 2, I get an error message. As soon, as I remove one of them, make 
 works as expected.

 Maybe it is the wording that is misleading the 'any or all' may be meaning 
 'none or any one of the special keywords'.

 dev400t@dev400t-desktop:~/devel/make_test$ cat makefile

 .PHONY: datapluglib
 datapluglib : export override CC = g++
 datapluglib:
 echo $(CC)

 dev400t@dev400t-desktop:~/devel/make_test$ make
 make: *** No rule to make target `export', needed by `datapluglib'.  Stop.
 dev400t@dev400t-desktop:~/devel/make_test$ make --version
 GNU Make 3.81

No, the docs are correct *for the current version of GNU make*.  You
need to either
a) upgrade to the current version, or
b) read the documentation that was included in the version that you
have installed; try running info make

I suggest you also yell at your distribution for both not providing
the current version *and* for not pointing you at the correct
documentation for the version that they are shipping.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Example error in make manual

[Philip Guenther]

On Mon, Nov 5, 2012 at 3:26 AM, Zhitao Gong zhitaao.g...@gmail.com wrote:
 there should be no `=` after the `run-yacc`.

 On Mon, Nov 5, 2012 at 7:26 PM, Zhitao Gong zhitaao.g...@gmail.com wrote:
 in Make Manual Pdf, Edition 0.71, last updated 19 July 2010,

 Page 54:
 5.8 Defining Canned Recipes,

 the example
 define run-yacc =

No, the example is correct *for the current version of GNU make*.  You
need to either
a) upgrade to the current version, or
b) read the documentation that was included in the version that you
have installed; try running info make


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: sh embedding

[Philip Guenther]

On Mon, Jul 23, 2012 at 11:59 AM, icegood icegood1...@gmail.com wrote:
 from newer version of gnu make (3.81 under kubuntu 12.04)

 .PHONEY: all
 all:
 if [ \( $$(ls *.lock 2/dev/null) ==  \) ]; then \

The '==' operator is a bash extension that is supported by many but
not all shells.  Perhaps the shell seen by make on your kubuntu system
is one that doesn't support it?  The portable (30+ years!) equality
operator is =.

(The '==' operator was an extension that improved usability but added
no new functionality and instead reduced portability; thanks, bash
maintainers, for screwing everyone by making that tradeoff!)


 touch $@.lock; \

This check for lock file, if it doesn't exist then create it
operation is *not* 100% safe!  If two makes are run at almost the same
time, they may both see the file doesn't exist and then both touch the
lock file and continue, so the lock file is not actually guaranteeing
that only one copy is running.  You should see if there's a real
atomic lock file program on your system that you can use for this.
For example, I see a flock program on a Redhat system that could be
used, those the usage is a bit different.


 if [ \( ! -e $@ \) -o \( ../$(tag_fn) -nt $@ \) ]; then \
   echo $@ done; \
 else \
   touch $@; \
 fi; \

Isn't this the same as making $(tag_fn) a dependency of 'all' and
having 'all' *not* be PHONY?


 rm -f $@.lock; \
   else \
 sleep 1; \
   fi;

If the lock cannot be obtained, you just sleep a second and then
return success?  Why not at least exit 1 there so that the caller
can tell that the make failed in a consistent fashion?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: add Order-only Prerequisites example

[Philip Guenther]

On Sun, Jul 8, 2012 at 4:24 PM,  jida...@jidanni.org wrote:
 PS == Paul Smith p...@mad-scientist.net writes:
 A:B C;D
 A:|B C;D

 PS No.  C will never be run first, before B.  If you enable parallel builds
 PS then B and C might be run at the same time (but B will still be started
 PS first, then C).

Paul, as you know, you meant: *this rule* will not cause C to be run
before B; if *this rule* is the trigger for B and C being built, then
B will be started before C.

An example of how C might be built before B, despite that rule being
used, would be

A: B C; D
E: C A

then make E will build in the order C B A E


 OK, I sure hope it will get documented that
 A:B C;D
 implies that if B fails, C will never get run (or built etc.),

What Paul said directly contradicts that.  He said:
 If you enable parallel builds then B and C might be run at the same time

If they're run at the same time, then obviously C will get built even
if B fails!


 and we never have to
 worry about C getting run first (unless we use some -option.)
 I.e., C will only get run after we know the results of B.

Nope, wrong.  If you want make to guarantee that, you must express it
as a dependency between C and B.


Philip Guenther

___
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

[Philip Guenther]

On Tue, Jun 12, 2012 at 12:59 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
 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 T2 # 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

 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.

Given the design of make, with its lazy DAG building, what you are
asking for cannot be done automatically by make, as when it hits T2 as
a prerequisite it cannot know whether a not-yet-considered target will
end up having T1 as a prerequisite.

My gut reaction is that something in this setup is over-simplifying
things or misleading make.  If T1 needs to be done before T2 _ever_,
then why not _always_ have it as a prerequisite of T2?  Is the
.PHONYness of T1 a hack to get around some other limitation and using
some sort of timestamp file would let T1 be not-.PHONY and always be a
dependency of T2?

Whatever.  Insufficient data.  Workaround: use the MAKECMDGOALS test
previously cited but list all the targets that depend on T1 as well in
the $(filter) clause.


Philip Guenther

___
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

[Philip Guenther]

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?

(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

___
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

[Philip Guenther]

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


     $ 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


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #35132] Side effects of .SECONDARY with no targets not documented

[Philip Guenther]

On Tue, Dec 20, 2011 at 2:07 PM, anonymous invalid.nore...@gnu.org wrote:
 There are some side effects associated with intermediate/secondary targets
 that aren't documented in any real detail in the documentation.

 The documentation for .SECONDARY gives the impression you can use .SECONDARY
 to disable automatic deletion of intermediate targets, but doing so causes a
 number of side effects that produce unpredictable behavior in a build.

 Unfortunately, I do not have a concise or publishable example demonstrating
 the problem; however, I outlined it on this thread:

 http://groups.google.com/group/gnu.utils.bug/browse_frm/thread/d882703f60b20ea5?hl=en#

To confirm, when you say thread, you mean my single post, right?
I want to be sure that link isn't leaving off replies or something...

That said, your post references rules that build symlinks to other
files...and then you leave out important details of the cases that
cause problems.  If you don't have the time to find a minimal test
case, can you at least spend the time to figure out the conditions
under which the problem occurs?  If not, how are we, who don't have
access to your system, supposed to figure that out?  You might get
lucky...or you might just be pissing into the wind.

So: does the problem only occur when the symlink already exists?  Or
when the symlink *doesn't* exist?  Is this a recursive make setup?  If
so, which makefiles have which rules?  How can we debug this when you
don't provide *ANY* examples of a rule for building one of those
symlinks?

As for issue problem with .PRECIOUS, well, it works with patterns for
me; please provide an actual example.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Fw: error

[Philip Guenther]

On Sun, Dec 4, 2011 at 10:03 AM, Rajendra Shivade
shivaderajen...@yahoo.in wrote:
...
 checking for suffix of object files... configure: error: in 
 `/home/durgesh/objdir/i686-pc-linux-gnu/libgcc':
 configure: error: cannot compute suffix of object files: cannot compile
 See `config.log' for more details.
 make[2]: *** [configure-stage1-target-libgcc] Error 1

This is a problem with gcc's configure script and/or your build
environment and has nothing to do with GNU make.  You've (apparently)
already posted your question to a mailing list for gcc; waiting for
help from there is the right thing to do.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds

[Philip Guenther]

On Fri, May 20, 2011 at 12:46 PM, David Boyce invalid.nore...@gnu.org wrote:
 My company makes drivers. The corollary is that we keep dozens if not hundreds
 of entire Linux kernel source build trees going back 10 years or so in order
 to build drivers for them. The way Linux kernel drivers are built makes it
 necessary to use the kernel build system. Thus it's not sufficient for us to
 fix our own makefiles, or even that Linux kernels which came out in the last
 year are fixed themselves. As things stand, we'll be unable to upgrade from
 GNU make 3.81 until all pre-2010 kernels have drained out of our support
 matrix, which could easily be another 10 years. Of course we also have the
 option of going back and fixing the makefiles for each old kernel, but once
 you've changed 2.6.18-128.7.1 then it's no longer 2.6.18-128.7.1.

Since gcc has changed many time across those years in ways that have
affected the Linux kernel build (the move to
__attribute__((always_inline)) comes to mind), don't you already have
to track a build environment for each kernel version?  I haven't
tried, but I believe that the current version of gcc will *not* build
a 10 year old kernel, or at least not a _working_ one.  For that you
need a 10 year old gcc, or at least something much closer to it in
time.  Well, the same applies to GNU make and may apply to other build
tools (binutils/as/ld?).  Whatever system you use for tracking gcc
releases should be applied to all the tools in the kernel build
environment.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Thu, Apr 21, 2011 at 3:50 AM, David Boyce david.s.bo...@gmail.com wrote:
 All quite true and admirably researched but this is not a
 standards-lawyering exercise, it's a software-engineering issue.

Why are you closing stdout instead of redirecting it to /dev/null?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33134] spurious error when stdout is already closed

[Philip Guenther]

On Wed, Apr 20, 2011 at 6:03 PM, David Boyce invalid.nore...@gnu.org wrote:
...
 Ironically, make's attempt to be super-duper careful about catching write
 errors to stdout (in the close_stdout function) results in a spurious error
 message when the user has already closed stdout:

 % cat makefile
 .PHONY: all
 all:; date

 % make 1-
 make: write error

 Patch attached.

Could you explain why you think that's spurious?  Make wanted to write
date to stdout and the write failed.  Seems legit to me.

(I'm not sure why it doesn't say make: write error: Bad file
descriptor like it does if you change the command invoked to :, but
that's a distinct issue.)


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching

[Philip Guenther]

On Tue, Mar 8, 2011 at 1:37 PM, Michael Witten mfwit...@gmail.com wrote:
 The `--dry-run' flag is supposed to be safe in that nothing
 in the file system is actually modified.

That's not actually true.  To quote the docs:

`-n'
`--just-print'
`--dry-run'
`--recon'
 No-op.  The activity is to print what recipe would be used to
 make the targets up to date, but not actually execute it.  Some
 recipes are still executed, even with this flag (*note How the
 `MAKE' Variable Works: MAKE Variable.).

and then later on the same page:

   The `-n', `-t', and `-q' options do not affect recipe lines that
begin with `+' characters or contain the strings `$(MAKE)' or
`${MAKE}'.  Note that only the line containing the `+' character or the
strings `$(MAKE)' or `${MAKE}' is run regardless of these options.
Other lines in the same rule are not run unless they too begin with `+'
or contain `$(MAKE)' or `${MAKE}' (*Note How the `MAKE' Variable Works:
MAKE Variable.)


At least part of that behavior is required by the POSIX specification
and has a few decades of history behind it.


Philip

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Intermittent parallel make rebuild failures

[Philip Guenther]

Looking backwards, this rule from your toplevel makefile:

 $(INF_DIST_SVCS_OBJS): $(DIRS)

seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
directories _below_ the list of directories in $(DIRS).  The toplevel
make may recurse, then on popping back out see that the *SOURCE
DIRECTORY* didn't change, and thereby decide that the object must not
have changed.

It looks me like your makefile is misleading make.

Can you give examples of the output of make when this stuff *isn't*
working?  Preferable minimal, of course, where only a single source
file was changed/recompiled, showing how make failed to rebuild
everything that it you wish it would, and then the output of the
second make invocation that builds the missing piece?ou


I don't trust dependencies on directories; you have a dependency on a
directory WHOSE CONTENTS AREN'T BEING CHANGED.  That raises florescent
red flags to me.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Intermittent parallel make rebuild failures

[Philip Guenther]

On Thu, Oct 7, 2010 at 9:22 AM, David Highley
dhigh...@highley-recommended.com wrote:
...
 Let us just cut to the essence of the issue we are running into, how do
 target prerequisites get processed in version 3.81 of make?

 Example:
 $(LIBRARY): $(INF_DIST_SVCS_OBJS)

 $(INF_DIST_SVCS_OBJS): $(DIRS)

 $(DIRS):

 .PHONY: $(DIRS)

 With parallel building how does the macro $(INF_DIST_SVCS_OBJS) get
 evaluated before the target $(DIRS) is done? Is there a method to stop
 this other than turning parallel building off?

Have you read the info pages section How `make' Reads a Makefile?
In it, it explains that variables in targets and prerequisite lists
are expanded immediately when the rule is read during the parsing of
the Makefile.  So, *before any targets have been built*,
$(INF_DIST_SVCS_OBJS) will be expanded twice during the parsing of the
above Makefile snippet, once when the $(LIBRARY) rule is parsed and
once when the $(INF_DIST_SVCS_OBJS) rule is parsed.

The -j option has no effect on that, so I don't understand your last
question above.  Or are you saying that this makefile is part of a
recursive make setup, so that it might be read multiple times, the
earlier of which could affect the latter of which?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

[Philip Guenther]

On Sat, Jul 31, 2010 at 7:19 PM, Peter Lawrence
peterl95...@sbcglobal.net wrote:
 On Jul 31, 2010, at 9:41 AM, Eli Zaretskii wrote:
           one thing I remember in detail about Sun's make, is that
 instead of writing a level number

 make[3]: ...
 make[2]: ...
 make[1]: ...

 it wrote out the directory that the commands had cd'ed to before
 recursing (and maybe the file name, can't be sure any more)

 make[foo/bar]: ...
 make[foo]: ...
 make[.]: ...

 GNU Make displays the equivalent Entering directory foo... and
 Leaving directory foo... messages.  Isn't that the same info?

 the words Entering and Leaving never appear in the output I captured

So are you going to read the GNU make info pages to see what
conditions make will generate those messages and how something might
have suppressed them?  Perhaps the gcc maintainers have decided that
they hate those messages and have told GNU make to not generate them.
If so, complaining to make developers will result in absolutely no
progress.  You need to figure out who actually has control over the
stuff that's bugging you.


 typical output from gnu-make when making gcc is such
 tossed-salad-scrambled-eggs that nothing is readable,
 most lines are hundreds of characters long, as you can
 see below the average is over 400 chars/line, here is
 some sample output from my failed build, you can't
 really tell much of anything from reading this output

That problem (monstrously long compile lines) has absolutely nothing
to do with make and there's nothing that make can do about it.  That's
just a problem with the makefile itself and needs to be taken up with
the authors of that.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: including makefile name and line number for shell_function_completed

[Philip Guenther]

On Sat, Jul 31, 2010 at 4:54 PM, Jon Grant j...@jguk.org wrote:
 I am using make 3.81 built for MinGW.

 How easy to output the Makefile.mak:line for each command that fails to start?

I don't think there's any way for a snippet of Makefile to figure out
what its line # and filename are.  The $(warning) function will
include them in its output, but I don't see any way to trigger that
based on the success or failure of a command without completely
changing how the makefile operates.

Hmm.

So, what's needed is for a future version of GNU make to provide some
way to get the current filename and line number.  Now, that could mean
a number of things.  The *obvious* answer would be to provide
$(filename) and $(linenumber) functions that expand to the line number
and filename where they are expanded.  I'm 80% sure that that's the
right choice.  Consider the following sort of makefile:
--
define rules
echo build $@ at $(filename):$(linenumber)
@touch $@
endef

foo:
$(rules)
--

Should the reported line number be that of the use of $(rules), or
should it be where $(linenumber) was writen?  I'm mostly convinced
that the answer is the former, but I have slight misgivings and I
suspect there are places where someone would want immediate expansion.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [RFC]serialize the output of parallel make?

[Philip Guenther]

On Thu, Jul 29, 2010 at 11:29 PM, Chiheng Xu chiheng...@gmail.com wrote:
...
 My suggestion is that you can implement it as an optional command line
 option(like -j), and on one or two primary platforms(Linux/Windows),
 instead of on all platforms.

So, the complexity of both possibilities.  You're writing, debugging,
and contributing this code yourself?

(I would hope that this wouldn't require any Linux-specific code;
perhaps you meant POSIX  Windows?)


...
 The scenario like make -j4 2/dev/null may be very rare, but
 scenario like make -j4  21 |  tee output.txt may be common.

And what, exactly, are you suggesting that make do to reflect that
guess about usage patterns?


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #29757] Target-specific variables change their flavor

[Philip Guenther]

On Fri, Jun 25, 2010 at 11:44 PM, Vitaly Grechko
invalid.nore...@gnu.org wrote:
 Follow-up Comment #2, bug #29757 (project make):
 Sorry. You were right. But this is not convenient to have just one way to
 append to a variable. Note that at least 2 *makes have :+= operator: dmake and
 fastmake. I guess GNU make could think about it.

Beware: even plain := isn't implemented the same everywhere, even if
you ignore the appending issue.  I've seen at least one version where
:= means expand the right-hand side immediately, and then otherwise
act like '=', with the result that the right-hand side is expanded
*twice*.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #29757] Target-specific variables change their flavor

[Philip Guenther]

On Fri, Jun 25, 2010 at 2:03 PM, Vitaly Grechko invalid.nore...@gnu.org wrote:
 Follow-up Comment #1, bug #29757 (project make):

 I think you are wrong. Simple or deferred expansion is connected to operator,
 not variable.

Maybe in some other *make program, but not in GNU make.  To quote
the info pages:

   For the append operator, `+=', the right-hand side is considered
immediate if the variable was previously set as a simple variable
(`:='), and deferred otherwise.


 Variable does not know what way it was assigned.

They do in GNU make.  Note that += isn't standardized.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Philip Guenther]

On Fri, Apr 30, 2010 at 5:46 AM, Edward Welbourne e...@opera.com wrote:
 The fix for that has been documented for years on Paul's webpage, and
 is most easily done now with gcc's -MP option.

 URL ?

http://make.paulandlesley.org/autodep.html#norule

(That explains the problem and what needs to be put in the dependency
files to solve it, and then gives an implementation that works with
all 'makedepend' methods; gcc's -MP option came later is is just an
optimized method for those using -MD)



Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

[Philip Guenther]

On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne e...@opera.com wrote:
 Delete a clean-depend rule on sight,

 I cannot agree.
 If I write a rule to make something, I also write a rule to get rid of
 it.  It's just basic hygiene ...

I propose the following guideline: If you have a target that generates
A (and B as a side-effect), then a 'clean*' rule that deletes B should
also delete A (and vice versa).

So, I do have a rule to delete *.d files, it's called clean.  Since
I don't have rules for building .d files other than with .o files, it
Just Works.


 or rename it to the more accurate break-future-builds.

 If you have a sensible rule to generate .d files when needed, you
 haven't broken your builds - you've just obliged yourself to
 regenerate .d files.  Which may be wasteful, but see below.

Okay, so if you have a rule to delete .d files without deleting .o
files, you need rules to build .d files.  In my experience, the only
reason to have *either* of those is because that's how the Makefile
was originally written and the current behavior doesn't hurt enough
for me to spend the time to fix it.


...
 Speaking of the subtleties of dependency tracking: do an update in
 your version control system, watch some header go away - and all files
 that used to reference it drop those references.  Your .d files claim
 a bunch of stuff depends on this missing file; but you have no rule to
 regenerate it.  So make will not even try to compile anything (even
 though everything *would* compile fine) because your .d file say that
 all the .o files that need recompiled depend on a file that doesn't
 exist any more; make clean-depend fixes that.

The fix for that has been documented for years on Paul's webpage, and
is most easily done now with gcc's -MP option.


 If generating .d as a side-effect, don't listen to the manual's advice
 that says you need to sed its content to claim that the .d depends on
 the same things the .o does.  If those things have changed, the .o
 shall be regenerated and hence so shall the .d; and you don't need
 this updated version of the .d file to discover that the .o needs
 rebuilt.  Changes to .h files consequently never trigger re-exec.

Ah, it looks like your comments are addressed at just what's in the
GNU make info pages and not the advanced method on Paul's webpage.  I
agree that what's in the info pages has many of the problems you
mention...which is why this thread is about updating what's there.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Static multiple target rules

[Philip Guenther]

On Mon, Mar 29, 2010 at 7:54 PM, tom honermann tom.honerm...@oracle.com wrote:
 Paul, would you be opposed to a patch that implements support for static
 multiple target rules using the above syntax?
 Any particular concerns or requirements you would have?
...
   a1 (b1 b2 b3): d1
       touch -r $^ $@

 Note the space between 'a1' and the left parenthesis.  This is required so
 that the target is not parsed as an archive member.

Hmm.  SysV make has offered the desired feature with the syntax

b1 + b2 + b3: d1
touch -r $^ $@

It appears the sysV implementation doesn't let you declare multiple
groups with a single rule, but that's not a restriction of the syntax
itself.  Yes, that syntax has a meaning in GNU make (treating '+' as a
target), but it's clearly not a portable name for a target.  (Indeed,
plus-sign is not part of the POSIX Portable Filename Character Set.)


The proposed syntax already has a conflicting special meaning in GNU
make (multiple archive-member target) for what would be the common
case of a single group.  That is, this:

(b1 b2 b3): d1
whatever

currently means the b1, b2, or b3 members of any archive library
depend on d1 and are updated by running 'whatever'.  The fact that
it's a special syntax means that it's more likely to actually be in
use out there.  How will the proposed change affect Makefiles using
that syntax?

(While I don't think the sysV syntax is *great*, I personally think
it's a better choice than overloading the meaning of parentheses.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Weird text-dependent bug in $(eval ...), simple test case

[Philip Guenther]

On Sun, Feb 28, 2010 at 6:25 PM, Jamie Lokier ja...@shareable.org wrote:
 Both of you have confirmed the bug - because the correct behaviour has
 no error messages, and you both got messages.  Neither of you was able
 to reproduce getting a text-dependent number of messages, but both of
 you see buggy behaviour so it's easy to reproduce a problem to investigate.

 Nobody wants to investigate this bug further?

Not to make an insane suggestion, but have you considered filing a bug
in the GNU bug tracking system, Savannah?
http://savannah.gnu.org/projects/make/

As a side note, I don't understand why you call this a bug in
$(eval)...as it's completely reproducible without using $(eval)!  Did
you try testing it directly?  If not, why not?

We've seen this on the list now multiple times: it seems that if
someone first encounters a bug while working with $(eval), they report
the problem as being in $(eval) and make no attempt to reproduce it
directly.  Since this is a hinderance to getting good bug reports, it
would help if you could examine why this happened in this case so that
it might possible be avoided in the future with others.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Prioritizing non-dependent targets in parallel make

[Philip Guenther]

On Thu, Dec 24, 2009 at 7:16 AM, Paul Smith psm...@gnu.org wrote:
 On Thu, 2009-12-24 at 01:08 -0800, tom honermann wrote:
 There are many valid orders in which the targets can be built.  When make
 is invoked with the parallel execution (-j) option, the order in which the
 non-dependent targets are scheduled has a significant impact on the total
 run time.

 You can already completely control the order in which targets are
 invoked, even when using -j.

 At all times, make will try to build prerequisites starting with the
 first one in the prerequisite list, and continuing in order to the last
 one in the list.

The problem is that only works for the direct dependencies.  I think
the OP's request is more about stuff buried more than one level deep.
E.g., program prog requires two libraries, each one of which has
multiple objects of varying size, with one object in each taking
particularly long to compile, say:

prog: prog.o liba.a libb.a
liba.a: a1big.o a2.o a3.o a4.o a5.o
${AR} rc $@ $^
libb.a: b1big.o b2.o b3.o b5.o b5.o
${AR} rc $@ $^

Now, let's say a2.o, a3.o, a4.o, a5.o and b1big.o are out of date.
make -j2 prog will rebuild them in that exact order, but it would
take less total time if make started rebuilding b1big.o first.  Static
reorderings of the prerequisite lists can't solve this.

Personally, while I'm sympathetic to the concern, I think this is the
sort of problem where the consequences of the solution are likely to
be greater than expected and it should probably be handed to some CS
grad student as a possible research project.  Isn't that what grad
schools are for, banging on possibly open-ended problems?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #27714] expansion of $(shell) in target forces serialization of targets

[Philip Guenther]

On Fri, Oct 16, 2009 at 4:34 AM, Paul D. Smith invalid.nore...@gnu.org wrote:
...
 But before it can invoke the recipe it has to expand all the variables and 
 functions.

I had to ponder that requirement for a bit before it occurred to me
that doing otherwise would either make $(eval) pointless in recipes or
make it an incredible, royal pain to implement.  Ditto for $(error).


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make to consider files checksum

[Philip Guenther]

On Mon, Sep 28, 2009 at 11:05 AM, Giuseppe Scrivano gscriv...@gnu.org wrote:
 it looks like a good idea.  Do you think it worths to be discussed with
 automake hackers?

I'm not actually convinced that this checksumming is a good idea,
mainly because I'm not convinced this is enough of a problem.  The
point of my message was just that this problem *can* be solved at the
makefile level.  Attacking it by changing automake sounds practical
and probably a faster way to a solution, though I would prefer it to
be optional even there.

(Have you measured how often this sort of thing would save
recompilation and/or relinking and how much time it would save then?
What's the comparison to how much time would be spent calculating the
checksums?  If it saves a minute once every 100 compiles but costs a
second in each of those, then it's a net loss...)

Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #27437] Problems with make in a directory with present Makefiles. make does not function.

[Philip Guenther]

On Mon, Sep 14, 2009 at 1:24 PM, anonymous invalid.nore...@gnu.org wrote:
 Follow-up Comment #2, bug #27437 (project make):

 aetixin...@aetixintro-desktop:/usr/src/snort-2.8.4$ ls

Read doc/INSTALL for directions.  In fact, scan most of the files in
the doc directory for help.

(I don't know why the snort people hide that file in a subdirectory,
unlike practically all other projects.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Why *** extraneous `endef'. Stop.?

[Philip Guenther]

On Sun, Sep 6, 2009 at 8:09 AM, Sergey Zubkovskyserg...@gmail.com wrote:
 It seems to me this is a bug.

 All will be fine if we just rewrite 'ifneq (1,1)' as 'ifeq (1,1)'.

 That is why I sent the question.
 I hope someone will add an item in the bug tracker (who know `make' better
 than me and will confirm this supposition).

Sure looks like a bug to me.  Note that this has nothing to do with
$(eval); it's presence in your example just confuses the issue.  You
can see the issue directly with this:

ifneq (1,1)
define var1
define var2
endef
endef
endif


I suggest you visit
http://savannah.gnu.org/projects/make

and submit the bug.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make to consider files checksum

[Philip Guenther]

On Fri, Apr 11, 2008 at 2:45 PM, Giuseppe Scrivanogscriv...@gnu.org wrote:
 I could find on this ML archives only a thread about this subject: to
 consider the file checksum instead of the timestamp.
 Other systems like scons already support this feature and it would be
 great to have it for GNU Make too.

This is a long dead thread (it's been sitting in my mailbox for a
year, ouch), but I'll throw in my two cents that a makefile can
implement this for itself with pattern rules.  Consider:


%.o: %.c
%.o.new: %.c
$(COMPILE.c) -o $@ $
%.o: %.o.new
@{ [ -f $...@.md5 ]  md5sum -c --status $...@.md5; } || \
{ md5sum $ $...@.md5; cp $ $@; }

.SECONDARY:
-

Poof, if you touch a .c file without making changes that affect the
compiler output, the executable will not be relinked.  Indeed, the
presence of the .SECONDARY target means the only thing that will be
rerun each time is the md5sum.

Yes, this is non-trivial to use, but it's also completely flexible,
letting you use whatever checksum comparison you want (need to strip
comments or RCS/CVS tags from the file before checksumming it?  Sure!)
and can be used Right Now.

Anyway, we now return you to your originally scheduled mailing list.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Segmentation fault in make-3.81

[Philip Guenther]

On Mon, Aug 3, 2009 at 2:22 AM, Glenn Coombsglenn.coo...@googlemail.com wrote:
...
 You're quite right and your solution above is indeed the sensible way to
 write it :-) However, I'd just been reading about the new features added in
 make 3.81 and was experimenting.

Well, be careful: $(eval) is great for removing fingers.  For example,
the value being assigned to CHIPNAME in this:
$(eval CHIPNAME := $(shell echo $* | tr a-z A-Z))

has expansion performed on it twice.  That almost certainly isn't a
problem in this case, but if you overlook it here
then you might not remember it when it does matter.  That line would
be better written, IMO, as:
$(eval CHIPNAME := $$(shell echo $$* | tr a-z A-Z))


 Still, having make throw a segmentation fault is bad so I figured it was
 worth reporting the issue so that the problem could be fixed.  After all,
 the next person to run into the same bug might not be using such a simple
 makefile with easy alternatives.

Sure.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Segmentation fault in make-3.81

[Philip Guenther]

On Fri, Jul 31, 2009 at 8:03 AM, Glenn
Coombsglenn.coo...@googlemail.com wrote:
...
 I encountered this issue when I added the eval at line 18 so that I could
 set CHIPNAME to the uppercase of the filename stub.

Is there some reason that you didn't use the solution that works in
every version of make that has ever been written and instead used a
complex solution that only has a chance of working in the most recent
versions of a single make implementation?

%_struct.h: %_struct.def
ifdef VERBOSE
CHIPNAME=`echo $* | tr a-z A-Z` ; \
$(REGCONV) -chipname $$CHIPNAME $ -simout $@
else
@CHIPNAME=`echo $* | tr a-z A-Z` ; \
echo Creating regconv header file CHIPNAME=$$CHIPNAME: $(notdir $@) ; \
$(REGCONV) -chipname $$CHIPNAME $ -simout $@
endif


If the duplication bugs you:

set_chipname = CHIPNAME=`echo $* | tr a-z A-Z`
regconv = $(REGCONV) -chipname $$CHIPNAME $ -simout $@
ifdef VERBOSE
  describe = echo $(regconv)
else
  describe = echo Creating regconv header file CHIPNAME=$$CHIPNAME:
$(notdir $@)
endif

%_struct.h: %_struct.def
@${set_chipname}; ${describe}; ${regconv}


(Yeah, it's a bug in make that it crashes on your makefile...but that
makefile just seems like the wrong way to solve your problem.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: .SECONDARY vs. .PRECIOUS doc of danger

[Philip Guenther]

On Mon, Jun 29, 2009 at 9:32 AM, jida...@jidanni.org wrote:
 You fellows have a lot of explaining to do. (On the Info page, not to me.)

 In (info (make) Special Targets)
 `.PRECIOUS'
     ...Also, if the target is an intermediate file, it will not be
     deleted after it is no longer needed, as is normally done... In
     this latter respect it overlaps with the `.SECONDARY' special
     target.

If you keep reading you'll see this:

 You can also list the target pattern of an implicit rule (such as
 `%.o') as a prerequisite file of the special target `.PRECIOUS' to
 preserve intermediate files created by rules whose target patterns
 match that file's name.

In contrast, the description of .SECONDARY only mentions targets and
not target patterns.


 However we see that only genuine .PRECIOUS will preserve the
 intermediate file. .SECONDARY, on the other hand, will blow - it - away.

 $ ls
 Makefile  u.kml
 $ cat Makefile
 .SECONDARY:%.kmz

As documented, .SECONDARY does not support target patterns, so the
difference in behavior is expected.



Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Section 3.8 of the info manual not respected

[Philip Guenther]

On Tue, May 26, 2009 at 9:45 AM, Anthony Shipman a...@iinet.net.au wrote:
 I've tried the example in section 3.8 Overriding Part of Another Makefile.
 i.e.

 foo:
        frobnicate  foo

 %: force
       �...@$(MAKE) -f Makefile $@

 force: ;

 The command 'make foo' results in

 make[1]: Makefile: No such file or directory
 make[1]: *** No rule to make target `Makefile'.  Stop.
 make: *** [GNUmakefile] Error 2


The paragraph just above the example says this:

   For example, if you have a makefile called `Makefile' that says how
to make the target `foo' (and other targets), you can write a makefile
called `GNUmakefile' that contains:


I.e., you *first* must have a file Makefile in the current
directory.  The error message you got says that you don't have that,
so of course the example doesn't work.

Since you don't have a Makefile already, why are you trying to use an
example for overriding an existing makefile?


 An implicit rule search is performed for the target GNUmakefile. This is not
 expected.

While GNU make will automatically try to rebuild its makefile, that's both
A) completely expected, and
B) not at all related the error message you quoted.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: automatic linking links too many files

[Philip Guenther]

On Mon, May 25, 2009 at 5:56 AM, Federico Poloni f.pol...@sns.it wrote:
...
 Thanks for the advice. I was not reporting this behavior as erroneous, but
 warning that it differs significantly from the documentation (Each kind of
 file automatically made into `.o' object files will be
 automatically linked).

Yes, the behavior doesn't match the docs.  I guess the question now is
which should be changed.  The current behavior is  better than what is
documented for at least two cases---archive files and linker
scripts---though the latter is quite obscure.  Fixing the docs to say
that the default rule will treat all prerequisites of the executable
as linker inputs seems better to me.


 In fact, there is this neat workaround:
 -Makefile contents
 $(phony foo):   textfile
 executable: $(phony foo)
 -
 but that was not my point.

Umm, what do you think the above actually does?  There's no built-in
function $(phony), so all you've done is removed 'textfile' from
'executable's prerequisite list.  If you change textfile, executable
will *not* be rebuilt!


 Additional remark:
 An executable depending from a text file may actually be needed in real
 life: e.g. in order to use the Gtk+ component GtkBuilder, the executable
 must read a `foo.ui' xml file which should be built from a `foo.glade' file.

Can you briefly enumerate the actual commands that need to be invoked
in such a setup, indicating what files are the input and output files
in each step (if it's not obvious)?

I ask, because I suspect you're mixing *build-time* dependencies and
*run-time* dependencies.  In a makefile, the prerequisites for a
target, executable or otherwise, should only be those needed at
build-time.  If foo.ui is read at runtime by the executable itself,
then the foo.ui is *NOT* a prerequisite of the executable.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: automatic linking links too many files

[Philip Guenther]

On Fri, May 22, 2009 at 8:04 AM, James Coleman jam...@dspsrv.com wrote:
...
 4.
 I notice that adding a static library doesn't get picked up by a default
 rule. I'm not going to dig further into this. My syntax for libs might be
 wrong, makefile.lib:
 executable: othercfile.o staticlibrary.a

 staticlibrary.a: yetanothercfile.o


 $ make -f makefile.lib
 g++    -c -o othercfile.o othercfile.cpp
 g++    -c -o yetanothercfile.o yetanothercfile.cpp
 g++     executable.cpp othercfile.o staticlibrary.a   -o executable
 g++: staticlibrary.a: No such file or directory
 make: *** [executable] Error 1

Almost.  To trigger the built-in library archiving rules you need this:

executable: othercfile.o staticlibrary.a
staticlibrary.a: staticlibrary.a(yetanothercfile.o)

$ make
g++-c -o othercfile.o othercfile.cpp
g++-c -o yetanothercfile.o yetanothercfile.cpp
ar rv staticlibrary.a yetanothercfile.o
ar: creating staticlibrary.a
a - yetanothercfile.o
g++ executable.cpp othercfile.o staticlibrary.a   -o executable
rm yetanothercfile.o
$


However:
1) the syntax is annoyingly redundant, using the .a name twice
2) it unnecessarily rebuilds the archive's symbol table after each addition
3) it breaks if you have multiple files in the archive and use parallel make

(If your system's ar doesn't rebuild the symbol-table by default, the
(2) doesn't apply, but your archives don't have symbol-tables!)

Much better is to write a command that handles all the changed archive
members in one go:

staticlibrary.a: yetanothercfile.o yacf.o
$(AR) $(ARFLAGS) $@ $?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: make falling over builtin rules ?

[Philip Guenther]

On Mon, Mar 16, 2009 at 6:13 AM, Stefan Seefeld ste...@codesourcery.com wrote:
 I have run into a situation where GNU make complains about circular
 dependencies, where there are none:
...
 src.cu.o: %.cu.o: %.cu
       �...@echo compiling...

 will result in the message:

 make: Circular src.cu - src.cu.o dependency dropped.
 compiling...

 When I replace '.cu' by '.cc', the warning / error message goes away.
 It also goes away if I disable builtin rules (via -r).

 Can you please confirm whether this is a GNU make bug, or user error ?

User error.  Generating ${base}.o from ${base} (where base=src.cu in
this case) is a reverse of the normal logic that ${base} is the
executable generated from ${base}.o.  So make is correct: there is
circular dependency.

The correct thing to do is not use the .o suffix in a way that
conflicts with the precedents going back to Unix version 7.

For example, instead of using .cu.o and .cu, use .cuo and .cu.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Enhancement request: Watch source files for changes

[Philip Guenther]

On Wed, Feb 4, 2009 at 8:25 AM, Noah Slater nsla...@gnu.org wrote:
 On Wed, Feb 04, 2009 at 03:59:45PM +, Tim Murphy wrote:
 I am not an expert on the source code but I think it is a fairly large
 change to try to apply to make.

 This would surprise me. Once the makefiles have been parsed and DAG has been
 built, GNU Make does a check of the filesystem. How hard could it be to put
 this last step in some kind of loop?

Putting the loop there would be incorrect, as then the dependency
graph wouldn't be updated when stuff changes in the filesystem.

(Caveat: I'm not a GNU make developer)

What seemed lacking to me in your original email was an analysis of
gains and losses of putting this functionality in to make.

- Why is this better built in than in a shell script wrapper (which
you already have!)?

- What problems with the shell script version are unsolvable there but solvable
  when built in?

- The shell script can be customized in a number of ways by simply
editing it.  Examples:
  o) changing the delay
  o) making the delay vary depending on whether anything was rebuilt
  o) triggering extra actions depending on whether anything was rebuilt
  o) filtering of output
  What's the plan for performing these customizations if this is built in?

- Is there precedent to this sort of enhancement, other build or
dependency tools
  that have done this sort of thing that could serve as a model?  If
this is completely
  a new area of design, then I would expect it to take several tries to get the
  behavior matching the user expectation

Those are just the sort of items I would consider if this was my
project; Paul and the other developers may have completely different
criteria in mind, but I would be surprised if they didn't overlap
some.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -include filename does not show correct dependency errors

[Philip Guenther]

On Wed, Jan 28, 2009 at 9:39 AM, willard pie...@willard.com wrote:
 it's the same if foo.d is not a direct target. It's even worse as make fails
 without ANY error message.

Nice!  xxx.h gets marked as failed and the error silenced, and the
silencing applies to all paths to xxx.h and not just the foo.d-xxx.h
path.


 See that the 'make -f bad2.mak' shows no message at all..(but going thru a
 makefile shows Error 2).

(echo $? after running make works too)


 I am sure I can find a work-around, but this seems like a nasty bug THAT
 SHOULD BE FIXED.

Whoa, no need to yell!  I didn't intend to suggest that the bug should
not be fixed.  My don't spend time banging you head comment was for
you, as a user of make, and not the developers of make (of which I am
_not_ one).

Hmm, since you feel strongly about this, the GNU make developers would
probably find it helpful if you were to verify whether this bug still
exists in the development (CVS) version of GNU make and, if so, file a
bug for it or, if there already is bug for it, comment on that bug.
If nothing else, that would let you be notified when the bug *is*
fixed.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -include filename does not show correct dependency errors

[Philip Guenther]

On Tue, Jan 27, 2009 at 8:59 PM, willard pie...@willard.com wrote:
 When using the -include filename(instead of just include filename), if
 this filename includes dependencies that are missing, makefile does not show
 those missing dependencies...

 For example, if using:

 -include foo.d

 with foo.d being:

 foo.o: foo.c xxx.h

 Let's say xxx.h does not exist (and cannot be generated) , the make fails,
 but it does not say it's because of xxx.h missing.

Well, what _does_ it say?  When I set up things to match your
description, it mentions xxx.h for me:

$ ls
Makefile foo.cfoo.d
$ cat Makefile
all: foo
-include foo.d
$ cat foo.d
foo.o: foo.c xxx.h
$ make
make: *** No rule to make target `xxx.h', needed by `foo.o'.  Stop.
$ make --version | head -1
GNU Make 3.81


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: -include filename does not show correct dependency errors

[Philip Guenther]

On Tue, Jan 27, 2009 at 9:44 PM, willard pie...@willard.com wrote:
 this is my example (create the foo.d manually as below)

Well, now that you've shown your whole Makefile, I have a guess as to
why make is behaving as it is.  It's tied that the face that you use
foo.d both as an implicit target (by virtue of being an included
makefile) and as an explicit target, as a dependency of 'all'.  My
guess is that when make first tries to build foo.d and fails, it marks
foo.d as unbuildable, but not why.  Later, when you have it try to
build foo.d (again), it sees that it has already marked it as failed,
so gives up directly.

My advice is to avoid this by fixing your auto-dependency method.  If
you just build the *.d files concurrently with the *.o files, then you
could avoid naming foo.d as either dependency or target.  The details
of why that works correctly and how to actually do that concurrent
building can be found in the Advanced Auto-Dependencies section of
http://make.paulandlesley.org/autodep.html

Yeah, make should give a less misleading error message, but why spend
time banging your head on a bug that could be avoided by making your
own code less wasteful?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: make --guaranteed-real-dry-run

[Philip Guenther]

On Thu, Jan 1, 2009 at 12:15 PM,  jida...@jidanni.org wrote:
 What really bugs me is we do man make, and see

   -n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute them.

 But that is just plain not always true, and one has to read the fine
 print in other documents to find the whole story.

So make a serious suggestion for the additional words that would have
clarified it for you.  Please don't try to use a footnote, as they
work poorly when a manpage is viewed on-line.  (Footnotes in
info-pages are only bearable because the viewer forcibly presents
them.)


 What I'm saying is that things like that at least need a asterisk and
 a footnote, else, well, how can you say with a clear conscience we
 warned you?

The GNU make manpage starts with this:

WARNING
   This  man  page  is an extract of the documentation of GNU
   make.  It is updated only occasionally,  because  the  GNU
   project  does  not use nroff.  For complete, current docu-
   mentation, refer to the Info file make.info which is  made
   from the Texinfo source file make.texi.

Since you continued to read past that, you apparently were unconcerned
that you were reading incomplete, possibly out-of-date documentation.

If you don't see that in your version, then you're either using an
out-of-date version of GNU make, or your system packager has rewritten
the manpage, placing it out of control of the GNU make developers.


 Yes down on the bottom is says for the full story see the info pages,
 but that's not how warning labels are done.

1) it's at the top, not the bottom, of the official manpage.
2) if that's not enough, then I suggest you remove the make manpage
from your system,
   as that's the only sure way to not have incomplete data on it.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Philip Guenther]

On Wed, Oct 29, 2008 at 2:12 PM, Sam Ravnborg [EMAIL PROTECTED] wrote:
 On Sun, Oct 26, 2008 at 07:12:53PM -0400, Paul Smith wrote:
...
 Makefile:442: *** mixed implicit and normal rules.  Stop.

 config %config: scripts_basic outputmakefile FORCE
 $(Q)mkdir -p include/linux include/config
 $(Q)$(MAKE) $(build)=scripts/kconfig $@

 Here I try to catch the following:

 make config
 make menuconfig
 make xconfig
 make foobarconfig

 I must admit I cannot see the problem with mixing implicit and normal
 rules in the above. But I gues this is my simple use of it.

I see at least two ways in which it's confusing:
1) what prerequisites does foo have with this rule:
foo %.c: %.c.real
@: cp $ $@

2) rules with multiple pattern targets have special meaning to make:
   Pattern rules may have more than one target.  Unlike normal rules,
   this does not act as many different rules with the same prerequisites
   and commands.  If a pattern rule has multiple targets, `make' knows that
   the rule's commands are responsible for making all of the targets.  ...
I.e., this rule:
%.a %.b:
${commands}
says that building bar.a will also build bar.b, and
building quux.a will also build quux.b.  With this rule:
foo %.a %.b:
${commands}
should make assume that building bar.a will also build bar.b
*and* foo?
How about this rule:
foo blip %.a %.b:
${commands}
Will building bar.a also build bar.b, foo, and blip?
How about this one:
foo blip %.a:
${commands}
...whoops...


 Do you have any god suggestion how to rewrite this?

Option 1: if make config is really the same as make fooconfig,
then actually set that equivalence in the makefile with something
like:

config: fooconfig
%config: scripts_basic outputmakefile FORCE
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@



Option 2: if the list of config types is basically static, then just
list them explicitly:

CONFIG_TARGETS = config menuconfig xconfig foobarconfig
${CONFIG_TARGETS}: scripts_basic outputmakefile FORCE
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@


Option 3: if the list of config targets really does change regularly
or needs to be open-ended, then I would go with

CONFIG_DEP = scripts_basic outputmakefile FORCE
define CONFIG_COMMANDS
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@
endef

# normal and pattern targets are immiscible in a single rule
config: ${CONFIG_DEP}; ${CONFIG_COMMANDS}
%config: ${CONFIG_DEP}; ${CONFIG_COMMANDS}


(The version using $(eval) and $(foreach) is just icky looking in my mind)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Philip Guenther]

On Sun, Oct 26, 2008 at 2:48 PM, Paul Smith [EMAIL PROTECTED] wrote:
...
 Here's the issue: if you write a rule like this:

foo %.c: ; @: oops

 it actually works!  This, I believe, should be illegal.

Just to be clear, the problem with mixing a pattern with a normal
target is what happens when there's a pattern prerequisite, right?  I
mean, the example you gave at least has a sensical _possible_
interpretation, but this:
   foo %.c: %.c.real ; @: cp $ $@

doesn't, so make _has_ to detect and throw an error there.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Philip Guenther]

On Sun, Oct 26, 2008 at 4:14 PM, Paul Smith [EMAIL PROTECTED] wrote:
...
 Correct, although IMO just because it has a _possible_ reasonable
 interpretation isn't enough to overcome all the reasons why we shouldn't
 allow it :-)

I agree.  I just thought of another reason to dislike it:
  %.a %.b: foo ; @echo $@

will do the echo just once for a given pair of .a and .b files.  How
many times should it do it if there's a normal file in the target
list?

So I'm with you: either ban it, or warn that it's going away and ban
it 'next time'.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: possible bug in documentation for make

[Philip Guenther]

On Sat, Oct 25, 2008 at 1:42 PM, Daniela Rütting [EMAIL PROTECTED] wrote:
...
 1st problem: In an attempt to reduce tedious typing when defining a variable 
 from
 the command line, I tried:
 ifeq (max,$(O))
 O = -O3 -fomit-frame-pointer -fno-unroll-loops
 endif
 ifeq (,$(O))
 O = -O
 endif
 CXXFLAGS = -W -Wall $(O)
 but this didn t work. After typing  make O=max  the value  max  was passed 
 straight
 to the compiler instead of being changed to  -O3 -fomit-frame-pointer 
 -fno-unroll-loops.
 I had to use the more complex sequence
 ifeq (max,$(O))
 OPTIM = -O3 -fomit-frame-pointer -fno-unroll-loops
 endif
 ifeq (,$(O))
 OPTIM = -O
 endif
 ifndef OPTIM
 OPTIM = $(O)
 endif
 CXXFLAGS = -W -Wall $(OPTIM)
 It seems as if it is not possible to change the value of a variable inside an 
  ifeq
 conditional that test against that very variable, but I wasn t told in the 
 documentation.

This has nothing to do with the conditionals and everything to do with
mixing command-line and makefile assignments.  To quote section 9.5
Overriding Variables of the make 3.81 manual:
--
An argument that contains `=' specifies the value of a variable: `V=X'
sets the value of the variable V to X.  If you specify a value in this
way, all ordinary assignments of the same variable in the makefile are
ignored; we say they have been overridden by the command line
argument.
...
   There is one way that the makefile can change a variable that you
have overridden.  This is to use the `override' directive, which is a
line that looks like this: `override VARIABLE = VALUE' (*note The
`override' Directive: Override Directive.).
--y

Indeed, if you use 'override' in your makefile, then it works as you expect.



 I refer to: Edition 0.55, last updated 04 April 2000, of `The GNU Make 
 Manual', for
 `make', Version 3.79.
 I use: GNU Make version 3.79.1, Built for i386-pc-msdosdjgpp
 (not the newest version, I presume, but maybe no one mentioned the problem 
 yet?)

So you're using a version of make that has been obsolete for *6
years*, but haven't checked the new manual?  (3.80 was released on
2002-10-03; 3.81 on 2006-04-01)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: reporting requirements

[Philip Guenther]

On Fri, Aug 22, 2008 at 1:40 PM, Ilya N. Golubev [EMAIL PROTECTED] wrote:
...
 expend the effort to do so

 This tries to represent things as if some terrible effort is required.
 Generally it is not so.

Oddly enough, that's not my experience.  When someone doesn't provide
enough data, the responder has three options:
A) write a completely general reply.  For any non-trivial question,
this quickly becomes
impossible.
B) make assumptions.  If the assumption is wrong, then the answer is
worse than useless,
at it starts the search in the wrong direction.
C) ask for more data.

In my experience, the biggest difference between someone good at
debugging and someone so-so at debugging is that the former person is
MUCH more aware of what assumptions they are making and performs
sanity checks on those assumption as they go.  If you're going to
insist that people make assumption about your setup because you aren't
interested in describing it, then expect misleading answers.


 Instead, it requires much less work than
 writing the voluminous, useless (and hurting - to some, not me) reply
 that started the thread.

Huh.  You seem quite sure about how much work it takes for me to write
different types of replies.  Interesting.


...
 Agree that, personally, normally would have checked more before
 posting.  Why it was unacceptable to do that in that particular time
 with that particular issue is improper here.  My point is that users
 getting in such situations are inevitable time after time, and that
 such a behavior of users should be allowed,

Right, instead of ignoring them, we ask question to help narrow down
the problem.


 handled gracefully (as many RFC say).

Heh.  Many of those RFCs also specify error responses to send when the
other end does something incorrect/non-compliant.  Guessing what the
other end meant is practically *banned* in many IETF protocols due to
the horrible experiences of some early protocols.  I recommend Paul
Vixie's published papers about BIND and how the handle gracefully
mentality resulted in security holes in DNS.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: does not rebuild Makefile.in

[Philip Guenther]

On Tue, Aug 19, 2008 at 1:55 PM, Ilya N. Golubev [EMAIL PROTECTED] wrote:
...
 Occurs in any `Makefile' obtained from
 Makefile.in generated by automake 1.10.1 from Makefile.am.
 so reproducing should be easy.

You'd rather make people download and install something they may not
need instead of copy-n-pasting the Makefile into to your email.  Nice
way to be helpful there when asking for help!

Note that you haven't actually provided enough information to
reproduce the situation even if I did have a copy of automake 1.10.1
on hand: what specific package was this with?  What arguments were
passed to 'configure'?  What directory layout?  What arguments passed
to make?  Are we supposed to just *guess*??!


 All `Makefile' modification was removing `Makefile' target.

Umm, what?  If you remove the 'Makefile' target, then why would make
care that the Makefile.in file is out of date?  Are you including it
as a target on the command line?  For that matter, how are you
invoking make in your tests?  Please describe the behavior when you do
*not* edit the Makefile to remove the 'Makefile' target.


 The reason was obvious: otherwise `make' would fail due to `Makefile' not
 remade.

Could you please show the actual command output and error messages and
makefile contents?


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: $(eval) expansion within $(eval)

[Philip Guenther]

On Tue, Apr 15, 2008 at 2:47 PM, Tony Strauss
[EMAIL PROTECTED] wrote:
 Calling $(eval) within $(eval) can lead to very unintuitive (at least to me
 :) behavior.  In particular, the inner $(eval) is expanded *and* executed
 during the expansion of the outer $(eval).

Right, because make needs to know what the inner $(eval) expands to so
that it knows what the outer $(eval) is getting as its argument.


 For instance (I've also attached
 this example, since my email client mangled the tabs in the code below):

 define func2
   MY_FUNC2_VAR := $$(SOME_VALUE)
   all::
@echo Here2: $$(MY_FUNC2_VAR)
 endef

 define func3
   MY_FUNC3_VAR := $$(SOME_VALUE)
   all::
 @echo Here3: $$(MY_FUNC2_VAR)
 endef

 define func1
   SOME_VALUE := 1
   MY_FUNC1_VAR := $$(SOME_VALUE)
   all::
 @echo Here1: $$(MY_FUNC1_VAR)
   $(eval $(call func2))
   ifndef SOME_VALUE
  $(eval $(call func3))
   endif
 endef

 $(eval $(call func1))
 all::

Umm, why are you using $(call funcN)?  Since you're not passing any
arguments and they aren't recursive, that's the same as $(funcN).

(This appears to be a common misconception, that $(call) is needed
with $(eval).  It's not.)


 The execution of the inner $(eval)s before the execution of the outer
 $(eval) means that:
 1.) SOME_VALUE is not defined when either func2 or func3 is executed.
 2.) func3 is expanded and executed despite being within a conditional that
 never will be true.

Right.  If you don't want those effects, then don't use inner
$(eval)s!  If you leave out the $(eval)s and just reference $(func2)
and $(func3) inside the definition of func1, those issues don't arise:

define func1
  SOME_VALUE := 1
  MY_FUNC1_VAR := $$(SOME_VALUE)
  all::
@echo Here1: $$(MY_FUNC1_VAR)
  $(func2)
  ifndef SOME_VALUE
 $(func3)
  endif
endef


$ make
Here1: 1
Here2: 1
$


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #20501] MAKEFLAGS += -rR doesn't turn off default suffix rules, variables

[Philip Guenther]

On Jan 23, 2008 4:33 AM, Hendrik de Goede wrote:
 To quote the make 3.81 documentation 'You can also set MAKEFLAGS in a
 makefile, to specify additional flags that should also be in effect for that
 makefile', in the same chapter you specified.

Unfortunately, it's not clear how MAKEFLAGS += -R can be made to
work as desired, as the built-in variables are set before the user's
makefile is parsed.  For example, what's it suppose to do with this
Makefile:

all: foo-$(shell echo $(RM))
foo-rm:
@echo rm
foo-:
@echo nothing
ifdef RM
MAKEFLAGS += -R
endif

Does the MAKEFLAGS setting force a reexec?  To give the 'all' target
the 'correct' prereq list would require that.  Hmm, what if you
_remove_ -R from MAKEFLAGS?

Or maybe I'm over analyzing.  What if the effect of adding -R to
MAKEFLAGS was that make immediately unset all variables whose origin
is 'default'?


Hmm, the operation of the -r option (which is implied by -R, yes) is
actually worse, as there's no way to remove a rule from make's memory.
 Then again, is there any way to detect that a rule exists from inside
a Makefile?  If not, then make could delay the addition of the
implicit rules until the makefile is completely parsed, albeit with
some ugly complexity to do the insert these as if they had occurred
before all other rules effect.  E.g., if the makefile has this:
%:: %,v
then the RCS checkout rule has to remain canceled.


That's looking line a ton of complexity to achieve logical
completeness.  Even though the main project I have builds slightly
faster (and just as correctly) when the -R option is given, I don't
find myself worrying about it.  I would much rather have GNU make
behave like it does than have it handle MAKEFLAGS+=-Rr as I suggested
above at the cost of new, subtle processing bugs.  As cute as being
able to set -R from inside the makefile is, I just don't see it as a
feature that's worth introducing *any* bugs over.

I vote that Paul just change the info pages to document the current behavior.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Random Segmentation fault when run with -j n

[Philip Guenther]

On 10/20/07, Shahzad Muzaffar [EMAIL PROTECTED] wrote:
 I have this Makefile (attached) and when I run it with -j 8 then I get
 random segmentation fault(not always on same point). Running it without
 -j option works fine and I do not get segmentation fault all the time
 (it is just random).

This makefile causes no problems for me under OpenBSD, running either
version 3.80 or 3.81.  Yes, I ran it many times.  You should have
included the actual operating system that you're using in your bug
report.

You should also check whether you can reproduce this with GNU make
version 3.81, which has been out for over 18 months.


 My guess is that as I calculate values for some
 variable only on fly so may be when run with -j option, two threads try
 to calculate/access the same variable and that causes a crash.

GNU make does not use threads, so this explanation cannot be correct.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: bug? $(warning)/$(error) evaluated from inside a comment in a 'define'?

[Philip Guenther]

On 6/19/07, Stephan Beal [EMAIL PROTECTED] wrote:
...

When a $(warning) or $(error) is inside a 'define', it is evaluated even
if it is part of a comment.


The above statement is nonsensical.  If something is inside a define,
is not inside a comment.


define bogo
   # $(warning this should not be evaluated here: (bogo $(1)))
   abc := $(1)
endef
$(foreach ARG,abc def ghi,$(eval $(call bogo,$(ARG


Okay, so you've defined a variable, 'bogo', whose value consists of
two lines, the first of which has a '#' as its first non-whitespace
character.  It isn't a comment at that point, it's just a line with a
leading '#'.

So why isn't it being treated as a comment when you evaluate it?
Answer: it *is*, but the expansion of the variables and functions in
the value of 'bogo' takes place before 'eval' does anything.  Consider
this:

define bogo2
# $(warning foo! $(1))
endef
all:
   echo '$(bogo2)'
   echo '$(call bogo2,baz)'
$ gmake -f m2
m2:6: foo!
m2:6: foo! baz
echo '# '
#
echo '# '
#
$

When $(bogo2) is expanded, whether directly or via $(call), make
recursively expands the variables and functions inside its value.
That's all without $(eval) being used at all.



As far as i understand, comments are comments, regardless of the
context. ???


Not at all.  A comment is only a comment when being read, either as
part of the raw makefile or as the first step in eval's actual
operation.

(Then there are comments in the commands for rules, where if they're
indented with a tab then make sees them as normal parts of the
commands and passes them to the shell...which then will often ignore
them based on *its* rules.)


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make