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

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

[bug #40225] Deterministic output ordering

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

Re: [bug #40225] Deterministic output ordering

ly long time, because the build has to run sequentially. With deterministic ordering: make clean ; make --deterministic-ordering -j$(ncpus) > before.log 2>&1 # change something make clean ; make --deterministic-ordering -j$(ncpus) > after.log 2>&1 diff -u before.log after.log - Josh

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

Follow-up Comment #10, bug #33034 (project make): > Yes, formally it's not, but really, what's the chance a trivial one-line change to the top-level makefile will actually break your driver? :) It's actually several non-trivial multi-line changes to various makefiles in the Linux source tree.

Re: [bug #40225] Deterministic output ordering

that output. It'd be awesome, for instance, to have a JSON output mode for Make, or some other mode producing machine-parsable target-annotated output. However, there's still a huge amount of infrastructure out there that works really well wit

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

Follow-up Comment #13, bug #33034 (project make): You should check if "make foo.o" works, and if dependencies on either "all" or "foo.o" or both work as expected. I'll give the patch a try with an older Linux kernel and see if it fixes the build issue. I'm somewhat skeptical that removing the fa

[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 #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 #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

t seems insane to me to avoid > updating tools merely because of a few lines of makefile change in > kernels that are almost 4 years old. When doing archaeology on old kernels via git, you don't normally apply *any* patches if you can help it, because they're a pain to keep re-ap

Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

directed or piped would then make its output *not* a TTY, so that case would work automatically as well. Does this sound like a plausible solution? - Josh Triplett ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

[bug #48070] "make update" fails at wget of translationproject translations

URL: Summary: "make update" fails at wget of translationproject translations Project: make Submitted by: joshtriplett Submitted on: Tue 31 May 2016 12:37:34 PM PDT Severity: 3 - Normal

[bug #48070] "make update" fails at wget of translationproject translations

Follow-up Comment #2, bug #48070 (project make): I managed to work around it for now by running "make scm-update". You may want to consider pointing to that from README.git. ___ Reply to this item at:

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On Sun, May 29, 2016 at 11:04:49AM -0400, Paul Smith wrote: > On Sat, 2016-05-28 at 16:09 -0700, Josh Triplett wrote: > > If make's own stdout/stderr refers to a PTY, make could create PTYs in > > place of pipes, collect output that way, and synchronize it to its own > >