function.c (IS_ABSOLUTE) [__CYGWIN__]: Special definition for Cygwin.
(abspath) [__CYGWIN__]: Reset root_len to 1 if the absolute file name
has the Posix /foo/bar form.
[HAVE_DOS_PATHS]: Use root_len instead of hard-coded 2.
In this mode we still collect all the output from a given target and
dump it at once. However we don't treat recursive lines any differently
from non-recursive lines. Also we don't print enter/leave messages
after every dump. However we do ensure that we always print them once
to stdout, so the parent make will collect it properly.
Create a new file, output.c, and collect functions that generate output there.
We introduce a new global context specifying where output should go (to stdout
or to a sync file), and the lowest level output generator chooses where to
write output based on that context.
This allows us to set the context globally, and all operations that write
output (including functions like $(info ...) etc.) will use it.
Removed the "--trace=dir" capability. It was too confusing. If you have
directory tracking enabled then output sync will print the enter/leave message
for each synchronized block. If you don't want that, disable directory
tracking.
We tried to get some efficiency by avoiding a parse_file_seq() for simple
pattern prerequisites, but this also means no wildcard expansion was
happening, so add it back. Add regression tests for wildcards in target and
prerequisite lists.
POSIX does not guarantee that writes will be atomic if a file is
opened for normal (non-append) output. That means if multiple processes
are writing to the same file, output could be lost. I can't think of
a real use-case where we would NOT want append for stdout/stderr, so
force it if we can.
main.c (find_and_set_default_shell): Don't use file_exists_p or
dir_file_exists_p, as those call readdir, which can fail if PATH
includes directories with non-ASCII characters, and that would
cause Make to fail at startup with confusing diagnostics. See
https://sourceforge.net/mailarchive/message.php?msg_id=30846737
for the details.
In various places we were passing flags and characters to compare, then
using complex conditionals to see where to stop in string searches.
Performance numbers reveal that we were spending as much as 23% of our
processing time in these functions, most of it in the comparison lines.
Instead create a character map and use a single bitwise comparison to
determine if this is any one of the stop characters.