While GCC 4.x supports the usage of -fvisibility=hidden and the related
pragmas, usage of it under MinGW is a noop and should not be used.
Instead, __declspec(dllexport/dllimport) should be used instead to
indicate exportable functions.
Since Ninja builds a static library, no functions are exported and
visibility, at least under MinGW, is not an issue.
MinGW g++ recognizes -static as option to avoid the need to specify
individual libraries to be statically linked into the executable.
It also solves the warning of -static-libstdc++ not being recorgnized by
GCC 4.5.2 (TDM build)
The logic before was like:
for each output:
if edge_dirty or output.dirty:
output.dirty = true
edge_dirty = true
This was wrong in the case where the second output would case the edge
to be dirty; we needed to go back and mark the first output dirty as
well. Fixed by taking two passes: one to compute the dirty state,
then a latter sweep to mark all outputs.
Fixes issue 148.
Rather than taking whether the edge is dirty as an input, instead
only consider the arguments and return true/false, allowing the caller
to decide what to do with that information. (In the restat case we
were faking out the environment to get particular behavior for this.)
Should have no side effects, but this is part of fixing issue 148.
- Don't build browse.cc in bootstrap.sh.
- Explicitly call out to Python to run configure.py.
- Run ninja-bootstrap with no arguments to build the default target,
which is "ninja.exe" on Windows.
This reverts commit 38ab41f45ff818b437942b753328a0168914fc86, reversing
changes made to 819d6347b424f583d651b86dd1280605ddb23b88.
Platforms that don't have /usr/bin/python pointing to python2 are broken.
GetProcessId() is available only since Windows XP. Since
MinGW define WINVER to 0x0400 which is Windows 2000 I think, we have
a compilation error. Using GetCurrentProcessId() instead of
GetProcessId(GetCurrentProcess()) fix this issue.
1. For targets, when invoking ninja to build a target.
2. For targets, when doing a "query" command.
3. For command names.
4. For the subcommands of the "targets" command.
Also change CmdTargets() to call LookupNode() instead of GetNode() --
since the result was checked for NULL, that's probably what was intended
here originally.
Not sure why I just didn't write this right the first time; when running
a script for its output, the script is always an implicit input of the
output.
This tool performs a post-order traversal of the build graph, starting
from a list of targets specified on the command line, and for each
build statement encountered, prints the evaluated command line.
Use cases include:
- Generating input for a tool which needs to know the full command line
for every command invoked during a build. Many static analysis
and indexing tools require this information.
- Generating a build script which does not depend on Ninja.
For example, such a script could be used by Ninja to bootstrap
itself.
