Does anyone happen to know of a way to get the #line directive to output a relative path? I've had a quick look at the source, but there doesn't seem to be an obvious way to do this.
> mcpp foo/bar.c
produces:
# n "full/path/to/foo/bar.c"
This can produce very verbose downstream error messages, and I'd like to get gcc's behaviour, if possible, which is to output '# n "foo/bar.c".
Thanks-
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had a look at this, and it's hard-wired into the code; everything calls 'norm_path', which changes relative paths to absolute paths. This seems, at first sight, to be a strange decision. I can't see any advantage to this. Perhaps one of the supported OS'es doesn't have a 'cwd' concept?
The disadvantages are:
1 - back-end error messages will depend on the location of the source file, making regressions difficult
2 - back-end error messages are potentially confusing - you want to know that there's a problem in 'foo.c', not 'some-long-path-to-foo.c'
For reference, gcc's cpp handles this by finding the cwd of the input file, and then emitting paths relative to this cwd. This means that the back-end sees exactly what the programmer asked for - if he asked to include 'foo/bar.c', then the back-end get '# N "foo/bar.c"'.
-Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does anyone happen to know of a way to get the #line directive to output a relative path? I've had a quick look at the source, but there doesn't seem to be an obvious way to do this.
> mcpp foo/bar.c
produces:
# n "full/path/to/foo/bar.c"
This can produce very verbose downstream error messages, and I'd like to get gcc's behaviour, if possible, which is to output '# n "foo/bar.c".
Thanks-
Evan
I've had a look at this, and it's hard-wired into the code; everything calls 'norm_path', which changes relative paths to absolute paths. This seems, at first sight, to be a strange decision. I can't see any advantage to this. Perhaps one of the supported OS'es doesn't have a 'cwd' concept?
The disadvantages are:
1 - back-end error messages will depend on the location of the source file, making regressions difficult
2 - back-end error messages are potentially confusing - you want to know that there's a problem in 'foo.c', not 'some-long-path-to-foo.c'
For reference, gcc's cpp handles this by finding the cwd of the input file, and then emitting paths relative to this cwd. This means that the back-end sees exactly what the programmer asked for - if he asked to include 'foo/bar.c', then the back-end get '# N "foo/bar.c"'.
-Evan