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

David Boyce wrote: > I'm unsurprised at seeing no public response to > yours either. But disappointed. I'm not disappointed. Paul doesn't work for me so there is no obligation for him to write patches or design specs supporting my use cases. And neverthless, so far I've had no reason to be unha

[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 : > Please note I'm actually running my own compiled ve

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

Hi Paul, FYI: Steve Langasek wrote[1]: > As part of the initial deployment of multiarch support in Ubuntu, we've > discovered that some packages rely on make dependencies on "-lpthread" and > the like, which GNU make resolves internally to a library file. Since > multiarch means changing the pa

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?

Hi, jida...@jidanni.org wrote: > Is the man page really > GNU 22 August 1989 MAKE(1) > 21 years old? Or even > COPYRIGHT >Copyright (C) 1992, 1993, 1996, 1999 Free Software Foundation, Inc. >This file is part of GNU make. > 11 years old? The manual page was last modified on 29 Au

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

Hi Alex, Alex Samad wrote: > make -p -f/dev/null | grep -i include > make: *** No targets. Stop. > .INCLUDE_DIRS = /usr/include /usr/local/include /usr/include > > show me the default INCLUDE_DIRS and /usr/include is included twice. This is from read.c: static const char *default_inclu

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

tags 314306 + upstream quit Hi Paul et al, Simon Richter wrote[1]: > after spending quite some tme debugging less-than strict dependencies > with -j2, I thought it would be a nice addition if make were able to > attempt to invert the order of rule execution while still respecting the > order imp