![[logo]](/img/veripool_small.png)
Issue #444
vppreproc does not use relative directories for files in -F arguments
| Status: | Closed | Start date: | 02/24/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Wilson Snyder | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
-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.
History
Updated by Jeremy Bennett about 1 year ago
- File VerilogPerlRelFiles.patch added
I believe the attached patch (which also updates the test) fixes the problem.
Updated by Wilson Snyder about 1 year ago
- Status changed from New to Assigned
- Assignee set to Wilson Snyder
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.
Updated by Jeremy Bennett about 1 year ago
That seems a good strategy. Look forward to seeing the revised patch.
Also available in: Atom