This report applies to the behavior of the msvs generator for actions with
msvs_cygwin_shell: 0. The algorithm distinguishes between switches, which is
anything that begins with a hyphen or slash, and everything else, which it
treats as a file name and fixes it up to be relative to the project file. This
behavior is fine for arguments that are actually file names and not fine for
everything else, for which it creates utter chaos. It's not like this behavior
wasn't known when first written. Here's a comment in the msvs generator code:
# TODO(quote): This is a really ugly heuristic, and will miss path fixing
# for arguments like "--arg=path" or "/opt:path".
Apparently it never occurred to the author of this comment that false positives
would be more harmful than false negatives.
It's not like this is an inconsequential defect. This bad behavior is involved
in the one remaining dependency upon cygwin that V8 had:
http://code.google.com/p/v8/issues/detail?id=2658
V8 has a Python script with non-file positional parameters that were getting
clobbered by this behavior. The action function correctly under cygwin,
however, leading to the dependency.
For others reading this, there's a workaround. Just eliminate positional
arguments that are not file names, and don't use the equals sign syntax for
named arguments that take file names. In other words, just submit to the
classification that the msvs generator actually uses. In the V8 case above, the
Python script could be easily changed by using argparse. In other cases, an
invoker script could be written for the sole purpose of transforming the
command line syntax to conform to the limitation created by this defective
behavior.
The documented behavior is in a section titled "Pathname Relativization" in the
InputFormatReference page on the gyp wiki. That section contains a list of keys
that should be treated as pathnames. These lists are ignored in the actual
code, even "inputs" and "outputs", which are arguments to the action itself.
Original issue reported on code.google.com by e...@adblockplus.org on 25 Apr 2013 at 4:40
Original issue reported on code.google.com by
e...@adblockplus.orgon 25 Apr 2013 at 4:40