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

2013-10-09 Thread Josh Triplett
Follow-up Comment #8, bug #33034 (project make): Re comment #5: GCC is *exceptionally* careful about introducing backward-incompatible changes that break existing codebases, to the point where it provides options like -fpermissive to help older code continue to build. As long as you don't blindl

sinclude

2013-10-09 Thread Ted Lyngmo XX
Hi! I'm not sure if this is a bug but ... Regarding: sinclude $(file) This doesn't return an error if $(file) does not exist, which is expected. It also doesn't return an error if $(file) exists but isn't readable, which was unexpected and a difference between clearmake (which we are replacin

$(origin GNUMAKEFLAGS)

2013-10-09 Thread Oliver Kiddle
It seems that $(origin GNUMAKEFLAGS) returns `environment' while $(origin MAKEFLAGS) returns `file'. Is there a reason for this discrepancy? Unlike MAKEFLAGS, it doesn't appear to be exported to child processes. Even `file' seems a strange value: wouldn't default make more sense unless it really i

[bug #40225] Deterministic output ordering

2013-10-09 Thread Josh Triplett
URL: Summary: Deterministic output ordering Project: make Submitted by: joshtriplett Submitted on: Wed 09 Oct 2013 03:07:11 PM PDT Severity: 3 - Normal Item Group: Enhanc

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

2013-10-09 Thread anonymous
URL: Summary: Weird failure on Windows with OUTPUT_SYNC_TARGET Project: make Submitted by: None Submitted on: Wed 09 Oct 2013 10:27:54 PM UTC Severity: 3 - Normal Item Gr

[bug #40227] Various fixes for MSVC build of 4.0

2013-10-09 Thread Christian Boos
URL: Summary: Various fixes for MSVC build of 4.0 Project: make Submitted by: cboos Submitted on: Wed 09 Oct 2013 11:42:35 PM GMT Severity: 3 - Normal Item Group: Build/I

[bug #40227] Various fixes for MSVC build of 4.0

2013-10-09 Thread Christian Boos
Additional Item Attachment, bug #40227 (project make): File name: 0001-Fix-MSVC-build-using-the-NMakefile.patch Size:1 KB ___ Reply to this item at: ___

[bug #40225] Deterministic output ordering

2013-10-09 Thread Frank Heckenbach
Follow-up Comment #1, bug #40225 (project make): First, I wonder how deterministic the order in a non-parallel build actually is. I guess, formally it's not, but for practical purposes it is, i.e. given the same make version and the same makefiles, it's unlikely to change. When I had a need like

[bug #40225] Deterministic output ordering

2013-10-09 Thread Paul D. Smith
Follow-up Comment #2, bug #40225 (project make): A non-parallel build is actually fully deterministic for a given makefile. Make (I believe this is specified by POSIX) will always try to build the first prerequisite first, then the second, etc. Of course there are ways to get non-determinism: fo

[bug #40234] Ignored missing include in makefile causes "no makefile found" message.

2013-10-09 Thread padavo
URL: Summary: Ignored missing include in makefile causes "no makefile found" message. Project: make Submitted by: padavo Submitted on: Thu 10 Oct 2013 05:28:09 AM GMT Severity: 3 - Nor

Re: [bug #40225] Deterministic output ordering

2013-10-09 Thread Frank Heckenbach
Paul D. Smith wrote: > A non-parallel build is actually fully deterministic for a given makefile. > Make (I believe this is specified by POSIX) will always try to build the first > prerequisite first, then the second, etc. Of course there are ways to get > non-determinism: for example IIRC the $(