vppreproc does not use relative directories for files in -F arguments #444
Comments
|
Original Redmine Comment I believe the attached patch (which also updates the test) fixes the problem. |
|
Original Redmine Comment Thanks for the patch. I agree with what you're after, but the problem is I sometimes use Getopt to process other tool options which have flags in .f/.vc files such as "--someoption foo". The patch will treat foo as a filename and so would break them. So I'm thinking this should be both optional via a Getopt config option, and it should only add the / if the filename exists in the new place. vpreproc would set the option. If that makes sense I can easily modify the patch you provided to test the new option. |
|
Original Redmine Comment That seems a good strategy. Look forward to seeing the revised patch. |
|
Original Redmine Comment In 3.314. |
Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 444 from https://www.veripool.org
Original Date: 2012-02-24
Original Assignee: Wilson Snyder (@wsnyder)
-f and -F are used to pass a file of arguments to vppreproc. In the case of -F any arguments must be interpreted as relative to the directory containing the file of arguments.
It seems that any source file arguments in files specified with -F are not interpretive relative the directory containing the file, but to the original directory from which vppreproc was called.
The attached modification to test t/80_vppreproc.t demonstrates the problem.
For comparison, Verilator processes -F correctly.
I believe the problem is that vppreproc analyses non-file arguments separately from source files. Any source files are not therefore saved with the context of the directory in which they were specified.
The text was updated successfully, but these errors were encountered: