Re: Generating missing depfiles by an automake based makefile

I finally went back to the top of the thread. Dmitry> Here is a rule from an automake generated makefile. Dmitry> Below is a sample bash session with gnu make which demonstrates how a Dmitry> dummy shuffle.Po makefile fails to have shuffle.o rebuilt when Dmitry> shuffle.h changes. Dmitry> $ rm s

Re: Generating missing depfiles by an automake based makefile

Dmitry> i am not looking forward to -include (even though -include is Dmitry> supported by bmake, gnu make and sun make). Dmitry> -include robs the user the error message should make fails to rebuild a depfile. Dmitry> i'd rather introduce rules to rebuild depfiles, as presented in the Dmitry> ear

[bug #60730] Emit fewer enter/leave messages with -O

Follow-up Comment #2, bug #60730 (project make): > The reason for it is that when there are multiple jobs running we don't know if the next output to be printed will be from this instance of make or from another instance of make Thank you for your reply. I understand the problem. I think you ca

[bug #60730] Emit fewer enter/leave messages with -O

URL: Summary: Emit fewer enter/leave messages with -O Project: make Submitted by: tromey Submitted on: Fri 04 Jun 2021 04:33:01 PM MDT Severity: 3 - Normal Item Group: E

MAKEFLAGS set too late

Consider this Makefile: z := $(MAKEFLAGS) all: @echo $(z) I think that "make -j" should print "j". However, it does not: barimba. make -j barimba. This

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #27, bug #15919 (project make): Any word on a new release incorporating this fix? It has been over a year since this bug prevented GCC from implementing automatic dependency tracking: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01680.html __

Re: eval and if-blocks incompatible on i386-pc-linux-gnu

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> Interesting factoid: This bug is[*] also fixed (or perhaps was Dave> never exposed) in remake[**], which is still based on the 3.80 Dave> sources. I looked through the remake web site a bit -- this looks pretty cool, especially now that

Re: Misleading RCS behaviour

> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes: Paul> Without GPATH, new files checked out will be placed in the target Paul> directory; with it they will be updated in the source directory. We could add that, but we couldn't rely on it. Well, maybe we could, since really we only suppor

Re: Automake: Compiling sources in other directories

> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes: Dave> To work around the problem I have to change the generated dependency to: Dave>h1.lo: ../host/h1.cpp Dave>$(LTCXXCOMPILE) -c -o $@ $< Dave> Is this a make bug, or should automake be generating a rule for Dave> making hl.l