[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Additional Item Attachment, bug #30723 (project make): File name: origin-breakage.tar.bz2Size:0 KB ___ Reply to this item at: ___ Message sent

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Follow-up Comment #2, bug #30723 (project make): i tried to recreate a reduced test case but failed, but then i realized i was testing on a diff machine that had make-3.81 here is a simple reduced test case ... forget about glibc ;) $ tar xf origin-breakage.tar.bz2 $ cd origin-breakage $ make-3

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Follow-up Comment #1, bug #30723 (project make): Hm. Is there any way for you to provide a smaller example? I tried to follow your directions but I think the build failed for some other reason, earlier than the problem you hit: make[2]: *** No rule to make target `.../glibc-2.11.2/build/elf/so

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

URL: Summary: implicit re-executing of subdirs breaks $(origin) with make-3.82 Project: make Submitted by: vapier Submitted on: Tue 10 Aug 2010 05:22:11 AM GMT Severity: 3 - Normal

Re: Override... but not really

On 8/9/10 6:07 PM, Paul Smith wrote: On Mon, 2010-08-09 at 14:00 -0700, Philip Prindeville wrote: The offender I'm staring at right now is ppp-2.4.5. I'll try to autoconfiscate it (autoconf + obsfucate?) later. I wasn't suggesting you should autoconfiscate it. I was suggesting the maintainer

Re: Override... but not really

On Mon, 2010-08-09 at 14:00 -0700, Philip Prindeville wrote: > The offender I'm staring at right now is ppp-2.4.5. > > I'll try to autoconfiscate it (autoconf + obsfucate?) later. I wasn't suggesting you should autoconfiscate it. I was suggesting the maintainers of the package should. PPP is a

Re: insufficient debug info from gnu-make

Peter Lawrence wrote: great if you want to see what was actually executed, not so great if you want to figure out where in the make sources you need to start looking, both are realistic wants. when things get as messy as gcc's makefiles, I'ld like to be able to see both the before and after

Re: Override... but not really

On 8/9/10 1:46 PM, Paul Smith wrote: On Mon, 2010-08-09 at 12:41 -0700, Philip Prindeville wrote: Alas much of this is beyond my control, and it's not a single project: it's a Linux distro having a couple of hundred projects, many of which have several directories deep of makefile nesting. Ah,

Re: Override... but not really

> I do a lot of cross-compilation, where the platform requires a set > of CFLAGS to always be present, such as -march=xxx and > -isysroot= ... Suggestion: Set CROSS = -march=xxx -isysroot=yyy where you're currently trying to hack CFLAGS and have makefiles that are actually going to use CFLAGS

Re: Override... but not really

On 8/9/10 12:12 PM, Paul Smith wrote: On Mon, 2010-08-09 at 11:54 -0700, Philip Prindeville wrote: I guess I was thinking that variables are exported between makes the same way that environments variables are passed between processes. Well, certainly variables CAN be exported by make (see the

Re: Override... but not really

On Mon, 2010-08-09 at 12:41 -0700, Philip Prindeville wrote: > Alas much of this is beyond my control, and it's not a single project: > it's a Linux distro having a couple of hundred projects, many of which > have several directories deep of makefile nesting. Ah, well, you didn't say so :-). One

Re: Override... but not really

On Mon, 2010-08-09 at 11:54 -0700, Philip Prindeville wrote: > I guess I was thinking that variables are exported between makes the > same way that environments variables are passed between processes. Well, certainly variables CAN be exported by make (see the "export" command) and passed to sub-ma

Re: Override... but not really

On 8/9/10 10:25 AM, Paul Smith wrote: On Mon, 2010-08-09 at 10:00 -0700, Philip Prindeville wrote: Is this expected behavior? Yes. $ cat makefile1 override CFLAGS+=-DB $(info makefile1: CFLAGS=$(CFLAGS)) all: make -f makefile2 $ cat makefile2 $(info makefile2: CFLAGS=$(CFLAGS)) overr

Re: Override... but not really

Sorry, I sent that off and then realized that a little context might be more useful. I do a lot of cross-compilation, where the platform requires a set of CFLAGS to always be present, such as -march=xxx and -isysroot= ... The problem is that if you pass these in from the command line as "

Re: Override... but not really

On Mon, 2010-08-09 at 10:00 -0700, Philip Prindeville wrote: > Is this expected behavior? Yes. > $ cat makefile1 > override CFLAGS+=-DB > $(info makefile1: CFLAGS=$(CFLAGS)) > all: > make -f makefile2 > $ cat makefile2 > $(info makefile2: CFLAGS=$(CFLAGS)) > override CFLAGS+=-DC > $(info m

Override... but not really

Is this expected behavior? $ cat makefile1 override CFLAGS+=-DB $(info makefile1: CFLAGS=$(CFLAGS)) all: make -f makefile2 $ cat makefile2 $(info makefile2: CFLAGS=$(CFLAGS)) override CFLAGS+=-DC $(info makefile2: CFLAGS=$(CFLAGS)) all: @echo foo $ make -f makefile1 CFLAGS=

[bug #30714] List of shell commands is outdated/Fallback to shell

Follow-up Comment #1, bug #30714 (project make): Unfortunately, the issue is a little bit more complicated: the MOVE command is a built-in on some versions of Windows, but an external program move.exe on others (Windows 9X). That (and not outdated information regarding the current Windows shells

[bug #30714] List of shell commands is outdated/Fallback to shell

URL: Summary: List of shell commands is outdated/Fallback to shell Project: make Submitted by: raspy Submitted on: Mon 09 Aug 2010 12:53:19 PM GMT Severity: 3 - Normal I

[bug #30340] dependency handling

Follow-up Comment #3, bug #30340 (project make): "When the .o file hasn't been created yet, knowing its .c source file is enough, and information on header file dependencies, while harmless, is of no practical use. " Well, that's not always true. Some projects use generated headers and use makef