What steps will reproduce the problem?
1. Create an action in an actions or rules list such as
'actions': [
{
'action_name': 'buildDoc',
'message': 'Generating documentation from Asciidoc source',
'inputs': [
'abc.txt',
'docinfo.html'
],
'outputs': [ '../../doc/abc.html' ],
'action': [
'asciidoctor', '-b', 'html5', '-o', '<@(_outputs)', '<@(_inputs)',
],
},
], # actions
2. Generate a project for any version of MSVS with the MSVS project file being
output to a different directory than the location of the .gyp file.
3. Observe that the command has become something like
asciidoctor -b ../../../../html5 -o ../../../../doc/abc.html ../../../../src/abc/abc.txt
Note that in my case the action is specified in a gypi file located at src/abc
relative to the including gyp file and the project file goes in
build/msvs/win/vs20XX relative to the .gyp file.
What is the expected output? What do you see instead?
What I would like to see is
asciidoctor -b html5 -o ../../../../doc/abc.html ../../../../src/abc/abc.txt
instead of the above which causes asciidoctor to quit complaining it has no
such backend as ../../../../html5
What version of the product are you using? On what operating system?
ToT
Please provide any additional information below.
What is happening is that the generator is relativizing all command line
arguments, unless prefixed with -, / or $, as if they were file names.
Everything appears to work when you use the Xcode generator because that sets
the project to run with the current directory set to the location of the .gyp
file, which means relativization is a NOP.
Move to an MSVS project and it breaks because when the project runs the current
directory is that containing the .vc{,x}proj file and all command arguments are
relativized to that.
I realise it is impractical for Gyp to understand every command you might run
and whether an argument is a file name or something else. So there needs to be
a way for the author of the gyp file to indicate if an argument is a file name
or not, perhaps a special prefix that will be removed from the final command.
Original issue reported on code.google.com by marksc2...@gmail.com on 7 Oct 2015 at 12:50
Original issue reported on code.google.com by
marksc2...@gmail.com
on 7 Oct 2015 at 12:50