Use relative path/dir msbuild variables to map $(InputDir) and $(InputPath)

Use relative path/dir msbuild variables to map $(InputDir) and $(InputPath)

$(InputDir) and $(InputPath) assume relative paths, but they're mapped to
%(RootDir)%(Directory) and %(FullPath) respectively. This makes gyp
generate incorrect commands for non-external rules in VS, for example:

-I ../foo/C:/bar/baz.h

(based on a generated command when building content_shell in VS)

MSBuild also provides variables for relative dir and path, so we should
use those instead to map $(InputDir) and $(InputPath).

Ran test/msvs and test/win test suites against VS2010 and VS2013, no regression.
Since VS maintains the cwd when building, using relative paths shouldn't affect
the current behavior. The only case where it might break things is if an
external script/command expects absolute paths for its arguments. I haven't
seen any instance of this while building content_shell and its dependencies.

BUG=

Patch from romain.pokrzywka@gmail.com.

R=scottmg@chromium.org

Committed: https://code.google.com/p/gyp/source/detail?r=1924

[scottmg, 2014-05-22 17:49:35]

This looks fine to me, but I'm not that familiar with these variables. Shez any
opinion? I can land it if it looks ok to you.

[Shezan Baig (Bloomberg), 2014-05-22 17:57:27]

I'm not familiar with these as well.  A standalone test might help make it
clearer (a test that fails without this patch, and succeeds with the patch
applied).

[Romain Pokrzywka, 2014-05-22 18:00:11]

On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> I'm not familiar with these as well.  A standalone test might help make it
> clearer (a test that fails without this patch, and succeeds with the patch
> applied).

Yes just thought about it in the meantime, working on it right now.

[Romain Pokrzywka, 2014-05-23 22:08:57]

On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> I'm not familiar with these as well.  A standalone test might help make it
> clearer (a test that fails without this patch, and succeeds with the patch
> applied).

Here's an updated patch set with a matching test case that fails without it,
sorry for the delay.
So there was an already existing test for my patch, which was unsurprisingly
excluding msvs :)
The good thing is that while testing the patch I found another corner case which
was still failing, and is now properly handled.

In short, the issue occurs when using RULE_INPUT_DIRNAME and RULE_INPUT_PATH,
which were translated by msvs to absolute paths rather than relative paths.
This affects both native and external rules, which is why I split the test to
demonstrate both cases. I've also added a couple more tests to improve overall
coverage.

[scottmg, 2014-05-24 03:42:16]

On 2014/05/23 22:08:57, Romain Pokrzywka wrote:
> On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> > I'm not familiar with these as well.  A standalone test might help make it
> > clearer (a test that fails without this patch, and succeeds with the patch
> > applied).
> 
> Here's an updated patch set with a matching test case that fails without it,
> sorry for the delay.
> So there was an already existing test for my patch, which was unsurprisingly
> excluding msvs :)
> The good thing is that while testing the patch I found another corner case
which
> was still failing, and is now properly handled.
> 
> In short, the issue occurs when using RULE_INPUT_DIRNAME and RULE_INPUT_PATH,
> which were translated by msvs to absolute paths rather than relative paths.
> This affects both native and external rules, which is why I split the test to
> demonstrate both cases. I've also added a couple more tests to improve overall
> coverage.

I started trybots, I suspect there might be generators where gyptest-dirname.py
is too specific now.

[Romain Pokrzywka, 2014-05-27 17:24:16]

On 2014/05/24 03:42:16, scottmg wrote:
> On 2014/05/23 22:08:57, Romain Pokrzywka wrote:
> > On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> > > I'm not familiar with these as well.  A standalone test might help make it
> > > clearer (a test that fails without this patch, and succeeds with the patch
> > > applied).
> > 
> > Here's an updated patch set with a matching test case that fails without it,
> > sorry for the delay.
> > So there was an already existing test for my patch, which was unsurprisingly
> > excluding msvs :)
> > The good thing is that while testing the patch I found another corner case
> which
> > was still failing, and is now properly handled.
> > 
> > In short, the issue occurs when using RULE_INPUT_DIRNAME and
RULE_INPUT_PATH,
> > which were translated by msvs to absolute paths rather than relative paths.
> > This affects both native and external rules, which is why I split the test
to
> > demonstrate both cases. I've also added a couple more tests to improve
overall
> > coverage.
> 
> I started trybots, I suspect there might be generators where
gyptest-dirname.py
> is too specific now.

Hi Scott,

Right, the new test I added for RULE_INPUT_PATH fails for the make and xcode
generators.
Should I just exclude these generators from running the must_match call in
gyptest-dirname.py (maybe with a big fat FIXME comment saying these generators
are not yet compliant), or would you prefer if I removed the new test
completely?

Thanks,
Romain

[scottmg, 2014-05-27 20:07:44]

On 2014/05/27 17:24:16, Romain Pokrzywka wrote:
> On 2014/05/24 03:42:16, scottmg wrote:
> > On 2014/05/23 22:08:57, Romain Pokrzywka wrote:
> > > On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> > > > I'm not familiar with these as well.  A standalone test might help make
it
> > > > clearer (a test that fails without this patch, and succeeds with the
patch
> > > > applied).
> > > 
> > > Here's an updated patch set with a matching test case that fails without
it,
> > > sorry for the delay.
> > > So there was an already existing test for my patch, which was
unsurprisingly
> > > excluding msvs :)
> > > The good thing is that while testing the patch I found another corner case
> > which
> > > was still failing, and is now properly handled.
> > > 
> > > In short, the issue occurs when using RULE_INPUT_DIRNAME and
> RULE_INPUT_PATH,
> > > which were translated by msvs to absolute paths rather than relative
paths.
> > > This affects both native and external rules, which is why I split the test
> to
> > > demonstrate both cases. I've also added a couple more tests to improve
> overall
> > > coverage.
> > 
> > I started trybots, I suspect there might be generators where
> gyptest-dirname.py
> > is too specific now.
> 
> Hi Scott,
> 
> Right, the new test I added for RULE_INPUT_PATH fails for the make and xcode
> generators.
> Should I just exclude these generators from running the must_match call in
> gyptest-dirname.py (maybe with a big fat FIXME comment saying these generators

I guess it's OK to exclude the new test from make and xcode.

Thanks

> are not yet compliant), or would you prefer if I removed the new test
> completely?
> 
> Thanks,
> Romain

[Romain Pokrzywka, 2014-05-27 22:11:17]

On 2014/05/27 20:07:44, scottmg wrote:
> On 2014/05/27 17:24:16, Romain Pokrzywka wrote:
> > On 2014/05/24 03:42:16, scottmg wrote:
> > > On 2014/05/23 22:08:57, Romain Pokrzywka wrote:
> > > > On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> > > > > I'm not familiar with these as well.  A standalone test might help
make
> it
> > > > > clearer (a test that fails without this patch, and succeeds with the
> patch
> > > > > applied).
> > > > 
> > > > Here's an updated patch set with a matching test case that fails without
> it,
> > > > sorry for the delay.
> > > > So there was an already existing test for my patch, which was
> unsurprisingly
> > > > excluding msvs :)
> > > > The good thing is that while testing the patch I found another corner
case
> > > which
> > > > was still failing, and is now properly handled.
> > > > 
> > > > In short, the issue occurs when using RULE_INPUT_DIRNAME and
> > RULE_INPUT_PATH,
> > > > which were translated by msvs to absolute paths rather than relative
> paths.
> > > > This affects both native and external rules, which is why I split the
test
> > to
> > > > demonstrate both cases. I've also added a couple more tests to improve
> > overall
> > > > coverage.
> > > 
> > > I started trybots, I suspect there might be generators where
> > gyptest-dirname.py
> > > is too specific now.
> > 
> > Hi Scott,
> > 
> > Right, the new test I added for RULE_INPUT_PATH fails for the make and xcode
> > generators.
> > Should I just exclude these generators from running the must_match call in
> > gyptest-dirname.py (maybe with a big fat FIXME comment saying these
generators
> 
> I guess it's OK to exclude the new test from make and xcode.
> 
> Thanks
> 
> > are not yet compliant), or would you prefer if I removed the new test
> > completely?
> > 
> > Thanks,
> > Romain

Done, and rebased against latest master. Should be all good now.

Thanks,
Romain

[Romain Pokrzywka, 2014-05-27 23:12:12]

On 2014/05/27 22:11:17, Romain Pokrzywka wrote:
> On 2014/05/27 20:07:44, scottmg wrote:
> > On 2014/05/27 17:24:16, Romain Pokrzywka wrote:
> > > On 2014/05/24 03:42:16, scottmg wrote:
> > > > On 2014/05/23 22:08:57, Romain Pokrzywka wrote:
> > > > > On 2014/05/22 17:57:27, Shezan Baig (Bloomberg) wrote:
> > > > > > I'm not familiar with these as well.  A standalone test might help
> make
> > it
> > > > > > clearer (a test that fails without this patch, and succeeds with the
> > patch
> > > > > > applied).
> > > > > 
> > > > > Here's an updated patch set with a matching test case that fails
without
> > it,
> > > > > sorry for the delay.
> > > > > So there was an already existing test for my patch, which was
> > unsurprisingly
> > > > > excluding msvs :)
> > > > > The good thing is that while testing the patch I found another corner
> case
> > > > which
> > > > > was still failing, and is now properly handled.
> > > > > 
> > > > > In short, the issue occurs when using RULE_INPUT_DIRNAME and
> > > RULE_INPUT_PATH,
> > > > > which were translated by msvs to absolute paths rather than relative
> > paths.
> > > > > This affects both native and external rules, which is why I split the
> test
> > > to
> > > > > demonstrate both cases. I've also added a couple more tests to improve
> > > overall
> > > > > coverage.
> > > > 
> > > > I started trybots, I suspect there might be generators where
> > > gyptest-dirname.py
> > > > is too specific now.
> > > 
> > > Hi Scott,
> > > 
> > > Right, the new test I added for RULE_INPUT_PATH fails for the make and
xcode
> > > generators.
> > > Should I just exclude these generators from running the must_match call in
> > > gyptest-dirname.py (maybe with a big fat FIXME comment saying these
> generators
> > 
> > I guess it's OK to exclude the new test from make and xcode.
> > 
> > Thanks
> > 
> > > are not yet compliant), or would you prefer if I removed the new test
> > > completely?
> > > 
> > > Thanks,
> > > Romain
> 
> Done, and rebased against latest master. Should be all good now.
> 
> Thanks,
> Romain

Sigh, Mac still failing, my bad I shouldn't have touched stuff that I wasn't
supposed to.
New patchset uploaded to fix the Mac trybot.

Thanks,
Romain

[scottmg, 2014-05-28 05:07:23]

lgtm

[scottmg, 2014-05-28 05:08:11]

Committed patchset #6 manually as r1924 (presubmit successful).