[bug #62809] Make grouped targets not evaluated as single logical file

Status: None ___ Follow-up Comments: --- Date: Mon 25 Jul 2022 03:01:35 PM UTC By: Jonathan Gravel The presence of the grouped target's peers are not considered when checking if the targ

Re: .PHONY missing from the manual's index

On 14/10/20 12:43 -0400, Paul Smith wrote: On Wed, 2020-10-14 at 13:18 +0100, Jonathan Wakely wrote: Shouldn't special targets like .PHONY be listed in the index at https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Concept-Index.html#Concept-Index_cp_symbol-9 ? Similarl

.PHONY missing from the manual's index

Shouldn't special targets like .PHONY be listed in the index at https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Concept-Index.html#Concept-Index_cp_symbol-9 ? Similarly for .SUFFIXES and others.

Building Make from Source, Cannot Find Shared Library

th --enable-rpath set in ./configure). Does anyone have experience with this? Thanks. Jonathan Shan ___ 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

Paul Smith wrote: > Today you're having an issue with make, but tomorrow it will be a change > in GCC, or binutils, or whatever... then what? Will you be asking GCC > to add a special flag to switch back to old behavior just to support > older Linux kernels? Not going to happen. Why is this dif

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

x27;ve had no reason to be unhappy with what he does. > I think the best approach is probably to follow the CVS commit trail, > find the commit which fixed the original bug, and Yes, that's probably good advice. Cheers, Jonathan ___ Bug-mak

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

Follow-up Comment #7, bug #33034 (project make): Just for the record, I have been looking for a spare moment to come up with a patch to fix this compatibility problem (which affects many projects other than the Linux kernel, too). If that's a bad idea for some reason, please feel free to let me k

make: it would be nice to get -R behavior using a directive inside a Makefile

Hi Paul et al, Here's a report[1] from Debian. I think he'd like a .NO-BUILTIN-VARIABLES: magic rule. Thoughts or advice? Thanks, 3.82.x is coming along nicely. :) Jonathan [1] Britton Leo Kerin wrote at <http://bugs.debian.org/620211>: > Please note I'm actually

Re: make needs to know about multiarch for expansion of -l target dependencies

es are moving to multiarch library > directories. LP: #737641. This all suggests to me that we need a getconf LIBRARY_PATH command so the same system-specific rules do not have to be reimplemented in every program that cares. Potential Debian-specific patch to just deal with this

Re: is the man page really 21 years old?

jida...@jidanni.org wrote: > >>>>> "JN" == Jonathan Nieder writes: > JN> The header line is somewhat arbitrary. If you have a good idea for > JN> what it should contain (in the form of nroff markup), I wouldn't be > JN> surprised if it gets use

Re: all commands should be echoed with "make -d"

David Highley wrote: > "Jonathan Nieder wrote:" >> Vincent Lefevre wrote[1]: >>> Debugging would be much easier if all commands are echoed (i.e. >>> including those starting with '@') with "make -d". [...] > Why do we need to modify make

Re: Adding FHS compliant directories to include path

Hi, Manoj Srivastava wrote: >> What do you think about creating (and looking at by default for include >> directives) another FHS complient directory for this kind of Makefile >> fragments, such as /usr/share/make/include for example ? > > In something as mature as GNU Make, I don't feel

Re: all commands should be echoed with "make -d"

Hi Paul et al, Vincent Lefevre wrote[1]: > Debugging would be much easier if all commands are echoed (i.e. > including those starting with '@') with "make -d". I suggest > adding the --debug option "e (echo)" for this purpose. Sounds like a good idea, and I don't know of anything existing like t

Re: is the man page really 21 years old?

have a good idea for what it should contain (in the form of nroff markup), I wouldn't be surprised if it gets used. Hope that helps, Jonathan ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #15338] make: stripping leading ./ causes flaky results

found 299892 make-dfsg/3.81-8 tags 299892 + upstream fixed-upstream quit Hi Andrew, Andrew Pimlott wrote: > make is doing something funny in the area of stripping the leading ./ > from filenames. Fixed by make-3-82~53 (Rework secondary expansion so we only defer it if there's a possibility it m

make: "Profiling timer expired"

Hi, Hugo Herbelin wrote[1]: > As witnessed by a search on the web, the meaning of the error > message "Profiling timer expired" is difficult to understand. I > guess, without being fully sure though, that it is caused by the > reception of a SIGPROF by make, what (apparently) means that gprof > h

Re: make: /usr/local/include is wrong priority in default include_dirs

documentation to some better methods if they exist. Thoughts welcome. Thanks for reporting, Jonathan ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

make: reordering targets built within dependency constraints (to debug a makefile)

eone wanting to try it out? Thanks for an interesting report and thanks for gmake. Jonathan [1] http://bugs.debian.org/314306 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

comments in eval

With GNU make 3.81-beta3, I try this makefile: define myvar # $(error blah) endef $(eval $(myvar)) And I get: Makefile:4: *** blah. Stop. Shouldn't the commented error call be ignored? Jon. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gn

Errors compiling make.c

Dear All I'm getting errors compiling misc.c. Functions message (222), error (258) and fatal (291) all generate conflict errors with the prototype make.h (396, 398 and 400). I'm using gnucc 3.3.2. What do I need to edit? All help gratefully received. Regards Jonathan --- Outgoi

Re: make 3.79.1: segfault in $(if ...) expansion

Sigh. I'm an idiot. I just realized that in fact I was testing this bug against make 3.78.1, not make 3.79.1, and it appears that the bug is already fixed in 3.79.1. Please disregard the bug report. Doh! Jonathan Kamens ___ Bug-make mailing

make 3.79.1: segfault in $(if ...) expansion

to one past the final argument. If my understanding is correct, then the patch below fixes this bug (and it does seem to work for me). Please remember to respond to me in addition to [EMAIL PROTECTED]; I don't read bug-make. Thanks, Jonathan Kamens Index: funct

Re: Only one pattern-specific variable assignment per target?

that > weren't acknowledged? I don't believe any of these messages were acknowledged: Date: Wed, 28 Feb 2001 12:03:49 -0500 From: Jonathan Kamens <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: make 3.79.1: should have "-

Re: Only one pattern-specific variable assignment per target?

you do decide to revert the implementation to how it was done in 3.78.1, note that I also submitted a patch against 3.78.1 to make multiple pattern-specific variable assignments work. Jonathan Kamens P.S. It would be nice if bug reports about Make were acknowledged in some way. P.P.S. Is [EMAI

make 3.79.1: should have "--no-builtin-includes" option

There should be a "--no-builtin-includes" option, corresponding to "--no-builtin-rules" and "--no-builtin-variables", telling Make not to look in any of the default directories for included Makefiles. This option is necessary for two reasons: 1) To allow people to limit accidental dependencies o

make 3.79: patsubst function vs multiple % in replacement text

of them, but it appears Make only substitutes the first. If the only-substitute-the-first behavior is indeed "correct", then I'd suggest the info file have a note added to document this. -- -- Jonathan Thornburg <[EMAIL PROTECTED]> http://www.thp.univie.ac.at/~jthorn/home.ht

Re: gmake 3.78.1 and (if) problems

't yet reported] too. I can not seem to recreate the $(if $(filter ...) ...) incorrect filtering right now, so can not confirm or deny that. [ but since I can't recreate it, I can't report it as a bug either, so let's assume it's gone too :) ]. Jonathan original mail fol

gmake 3.78.1 and (if) problems

dump, even when parentheses _are_ properly balanced, [but I'm having problems recreate those right now]. I include two makefiles which fail below, since one of them only fails when the target file doesn't exist, and the other one fails in both cases. Odd. Jonathan > rm foo r