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

Follow-up Comment #19, bug #33034 (project make): The attached version of boyski's patch with, as Paul suggests, just the change from fatal to error and the addition of "warning: ", fixes the kernel eg 2.6.32-5 driver build problem I otherwise have with eg make-3.82, make-4.0. (I've been using a

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

Follow-up Comment #20, bug #33034 (project make): It's great to hear that such a simple fix addresses this regression. As soon as this patch goes in, I'll follow up to the Debian bug about getting the patch backported, which should allow closing that bug and moving make from experimental to sid (

Re: [bug #40225] Deterministic output ordering

On Sat, Oct 12, 2013 at 7:01 PM, Frank Heckenbach wrote: > - My suggestion relies on the order the jobs are *started* (which, > as I said, ought to be deterministic and the same as with "-j0", > though Paul should know this better than me). Maybe you're talking about some restricted subcase,

Re: [bug #40225] Deterministic output ordering

Tim Murphy wrote: > One problem with reordering is how do you do it without actually > affecting the way you schedule jobs? Dunno, maybe just like I described it in http://lists.gnu.org/archive/html/bug-make/2013-10/msg00065.html > [...] > > So, you might say, it's not random because there are

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

Follow-up Comment #18, bug #33034 (project make): > That's disappointing. I've already explained why. Makefile syntax, unlike the C ABI where you can always just define a new function, is not inherently extensible except in very limited ways, and I'm not interested in creating ever more obscure

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

Follow-up Comment #17, bug #33034 (project make): > If it turns out that simply changing the fatal() to an error() is sufficient to resolve this, I'm willing to make that change (I won't add a flag for it; the message will simply say the syntax is unsupported and should be updated). Thank you.

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

Follow-up Comment #16, bug #33034 (project make): I admit I didn't understand the frustration level with this change. The Linux kernel was the only package that ever reported any real issues, and there were (by my count) a total of three patches (all minor) over the span of a couple of months aft

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #2, bug #40226 (project make): Could you please provide a minimal Makefile and a test case to reproduce the problem you saw? I'm sorry, but I have a difficulty understanding your description of the bug you found in the code; hopefully a test case will help me see the light. Tha

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

Follow-up Comment #2, bug #40227 (project make): Thanks for the patches! I had stumbled on a problem in which only the first command of a recipe would be printed. The second patch addresses that problem, as mentioned above. Cheers, Gerte Hoogewerf _

Re: [bug #40225] Deterministic output ordering

> Me too. I think we all basically agree that all of the above can be > useful, we just disagree on how hard each is to implement. I'm not > so sure these "very few little enabling features" are really such > small changes, whereas I think ordered output and/or individual log > files are easier to

[bug #40249] Test suite load and loadapi fail when make built with CFLAGS=-m32

URL: Summary: Test suite load and loadapi fail when make built with CFLAGS=-m32 Project: make Submitted by: None Submitted on: Sat 12 Oct 2013 11:21:08 UTC Severity: 3 - Normal

Re: [bug #40225] Deterministic output ordering

Edward Welbourne wrote: > > Or just use diff? > > That involves having two built directories, one holding the last build's > log files, the other holding the new build's; that may be OK, if you're > keeping all your old build directories (maybe as tar-balls) anyway, for > other reasons, but addin

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

Follow-up Comment #15, bug #33034 (project make): David Boyce wrote: > I agree with some of your points but there was a bit of cherrypicking involved in the quoting: > > > ... really, what's the chance a trivial one-line change to the top-level makefile will actually break your driver? > > I'm