Re: [bug #40225] Deterministic output ordering

>> The idea of diffing 2 builds is truly a cool one - especially when >> they're huge - but I'd rather it was done according to keys or other >> factors e.g. target name. >> I'd like to compare the time it took to build various targets and find >> out why a target took so much longer in the new bui

[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

Edward Welbourne wrote: > Then commit all the log files to git and use git show to find out which > of them have changed since the last build. (I trust you can all work > out the equivalent steps for *your* preferred SCM system.) This only > has to happen on the server that builds from clean on

Make 4.0 does not compile with MSVC 7.1

Contrary to the Statement in readme.w32 Make 4.0 does not comile with MSVC7.1. Output.c uses CRT features not available: 1) _TRUNCATE is unknown Workaround: use (size_t)-1 2) vsnprintf unknown Workaround: use _vsnprintf 3) _vsnprintf_s unknown Workaround: replace len = _vsnprin

[bug #40225] Deterministic output ordering

Follow-up Comment #3, bug #40225 (project make): Just a nit: on MS-Windows, $wildcard always returns file names in sorted order, because that's how the underlying filesystem behaves. ___ Reply to this item at:

Re: [bug #40225] Deterministic output ordering

On Thu, Oct 10, 2013 at 08:12:51AM -0400, Paul Smith wrote: > But I understood that the impetus for this feature would be to compare > builds between two completely different workspaces. It doesn't seem > very useful (to me) to ensure the order of two builds within the same > workspace since unles

Re: [bug #40225] Deterministic output ordering

On Thu, 2013-10-10 at 07:29 +0200, Frank Heckenbach wrote: > 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.

[bug #40236] include, -include and sinclude ignores failures to read the included file

URL: Summary: include, -include and sinclude ignores failures to read the included file Project: make Submitted by: None Submitted on: tor 10 okt 2013 12.13.16 Severity: 3 - Normal

Re: [bug #40225] Deterministic output ordering

> The idea of diffing 2 builds is truly a cool one - especially when > they're huge - but I'd rather it was done according to keys or other > factors e.g. target name. This sounds like a case for wrapping all rules in a generic output controller that can be configured (for an incremental build, ju

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #1, bug #40226 (project make): Second thought... I see now where the bug is coming from. Some use cases for the stringlist imply it's handled as a null-terminated array: for (pp=output_sync_option->list; *pp; ++pp) Some others iterate up to idx: for (idx = 1; idx <

Re: [bug #40225] Deterministic output ordering

I think this is something that's difficult to do and somewhat beside the point. It's lucky if you're someone for whom two builds even have all the same targets or all the same dependencies. The idea of diffing 2 builds is truly a cool one - especially when they're huge - but I'd rather it was don