wave: changing to relative paths in #line output?
I'm evaluating wave as a cpp replacement. I'm having a problem at the moment in that the #line output shows the name of the source file as an absolute path, and my regressions are expecting a gcc-style relative path. Before I have a go at hacking this, can anyone tell me if there's some configuration that can be set to output relative paths? Or to make the output more gcc/cpp-compatible? There are a couple of other minor differences to gcc and mcpp: wave produces '#line n', for example, and the others produce '# n'. Thanks - Paul
Paul,
I'm evaluating wave as a cpp replacement. I'm having a problem at the moment in that the #line output shows the name of the source file as an absolute path, and my regressions are expecting a gcc-style relative path.
Before I have a go at hacking this, can anyone tell me if there's some configuration that can be set to output relative paths?
There is no simple way to do so. But - depending on the urgency - this could be made available to you. It would be a matter of moving the formatting of the #line directives to a new preprocessor hook function, where you could customize the format in any way you prefer.
Or to make the output more gcc/cpp-compatible? There are a couple of other minor differences to gcc and mcpp: wave produces '#line n', for example, and the others produce '# n'.
What other differences do you have in mind? FWIW, the gcc way of formatting the line directives as '# n' is not standards conformant. Actually, this output results in an illegal preprocessing directive. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Hi Hartmut - Hartmut Kaiser wrote:
There is no simple way to do so. But - depending on the urgency - this could be made available to you. It would be a matter of moving the formatting of the #line directives to a new preprocessor hook function, where you could customize the format in any way you prefer.
If you can point me to anything specific in the wave source, then I can write some code and test it. If not, I'll write my own code to post-process your #line output to get it back to a relative form. I think this would be a (very) good feature (as well as being gcc-compatible). It makes it easier to read compiler error messages when the source files are spread over several directories, and makes the messages more compact.
Or to make the output more gcc/cpp-compatible? There are a couple of other minor differences to gcc and mcpp: wave produces '#line n', for example, and the others produce '# n'.
What other differences do you have in mind?
The only other difference I've noticed is that gcc always starts its output with a line directive for the first source file; you don't put in line directives until you need to. The gcc way is potentially useful, because the parser (or whoever gets the wave output) doesn't need to have its own independent knowledge of what the first source file was.
FWIW, the gcc way of formatting the line directives as '# n' is not standards conformant. Actually, this output results in an illegal preprocessing directive.
Ah. Maybe some of the gcc people work for MS? :) Thanks - Paul
There is no simple way to do so. But - depending on the urgency - this could be made available to you. It would be a matter of moving the formatting of the #line directives to a new preprocessor hook function, where you could customize the format in any way you prefer.
If you can point me to anything specific in the wave source, then I can write some code and test it. If not, I'll write my own code to post-process your #line output to get it back to a relative form.
I think this would be a (very) good feature (as well as being gcc-compatible). It makes it easier to read compiler error messages when the source files are spread over several directories, and makes the messages more compact.
Well, if you want to hack it directly, there is a function called pp_iterator_functor<>::emit_line_directive (see wave/util/cpp_iterator.hpp:+732) doing what its name says.
Or to make the output more gcc/cpp-compatible? There are a couple of other minor differences to gcc and mcpp: wave produces '#line n', for example, and the others produce '# n'.
What other differences do you have in mind?
The only other difference I've noticed is that gcc always starts its output with a line directive for the first source file; you don't put in line directives until you need to. The gcc way is potentially useful, because the parser (or whoever gets the wave output) doesn't need to have its own independent knowledge of what the first source file was.
Hmmm, you have a point here. Emitting a #line directive on the first line for the main file might be a good idea. Wave tries to minimize the output, but this one #line directive wouldn't make things worse. I'll see what I can do.
FWIW, the gcc way of formatting the line directives as '# n' is not standards conformant. Actually, this output results in an illegal preprocessing directive.
Ah. Maybe some of the gcc people work for MS? :)
Shhh, don't say that too loudly! :-P Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Hi Hartmut -
Well, if you want to hack it directly, there is a function called pp_iterator_functor<>::emit_line_directive (see wave/util/cpp_iterator.hpp:+732) doing what its name says.
It made more sense for me to change our code so that we can handle both relative and absolute paths; I now convert your path back to relative. The good news is that all our regressions pass when we replace cpp with wave. I'm now just hacking the boost distribution to pull your wave stuff out of it for stand-alone builds with make. thanks - Paul
Hi Paul,
there is a tool at boost which can handle it for you. Take a look at:
http://www.boost.org/doc/libs/1_42_0/tools/bcp/doc/html/index.html
Regards,
Ovanes
On Fri, Mar 19, 2010 at 11:15 AM, Paul Johnson
wrote:
I'm now just hacking the boost distribution to pull your wave stuff out of it for stand-alone builds with make.
Ovanes Markarian wrote:
there is a tool at boost which can handle it for you. Take a look at: http://www.boost.org/doc/libs/1_42_0/tools/bcp/doc/html/index.html
Thanks Ovanes - I found that yesterday (by accident!), and I'm just trying to build the quick_start example with the bcp output. I'm not quite there yet, but nearly... :)
I can extract the wave sources from boost and build the samples using bcp and gmake, but unfortunately I get three warnings. The first two warnings are in date_time, and were briefly discussed on this list last year, but there doesn't seem to have been a resolution; the third warning is in wave. Does bjam suppress these warnings? I haven't been able to work out the bjam build. I'm also using an old compiler (gcc 3.4.6), which might be relevant. Warnings: boost/date_time/gregorian/conversion.hpp:44: warning: missing initializer for member `tm::tm_sec' boost/date_time/posix_time/conversion.hpp:46: warning: missing initializer for member `tm::tm_sec' boost/wave/util/pattern_parser.hpp:41: warning: enumeral and non-enumeral type in conditional expression Suggestion: it's a pity that wave is only distributed as part of boost, given that it's so generally useful. It would be really nice if there was a stand-alone distribution in an svn repo somewhere. This would make it a lot easier to get updates. Thanks - Paul
Paul,
I can extract the wave sources from boost and build the samples using bcp and gmake, but unfortunately I get three warnings.
The first two warnings are in date_time, and were briefly discussed on this list last year, but there doesn't seem to have been a resolution; the third warning is in wave.
Glad to hear!
Does bjam suppress these warnings? I haven't been able to work out the bjam build. I'm also using an old compiler (gcc 3.4.6), which might be relevant.
Warnings:
boost/date_time/gregorian/conversion.hpp:44: warning: missing initializer for member `tm::tm_sec'
boost/date_time/posix_time/conversion.hpp:46: warning: missing initializer for member `tm::tm_sec'
Nothing I could do about those, I'm afraid.
boost/wave/util/pattern_parser.hpp:41: warning: enumeral and non-enumeral type in conditional expression
This warning is new to me, but I committed a patch which should suppress it
Suggestion: it's a pity that wave is only distributed as part of boost, given that it's so generally useful. It would be really nice if there was a stand-alone distribution in an svn repo somewhere. This would make it a lot easier to get updates.
Well, I won't be able to maintain two independent distributions, sorry. But I'm happy to hear the library is useful to you. FWIW, I'm still contemplating about making the generation of the #line directives customizable. Would you be willing to help testing such a feature? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
Paul,
FWIW, I'm still contemplating about making the generation of the #line directives customizable. Would you be willing to help testing such a feature?
No problem - let me know if/when you've got something.
Here is a list of things I implemented: - Added new preprocessing hook: emit_line_directive, allowing to customize the format of the generated #line directive. - Changed --line/-l command line option of the wave driver application to accept 0, 1, and 2 as options. The option values 0 and 1 behave as before (disable/enable the generation of #line directives), while the option value 2 will generate the #line directive using the relative filename (instead of the absolute filename emitted from option 1). The default option is value 1. - Added new example: emit_custom_line_directives, demonstrating the use of the new preprocessing hook. Do you mind checking this out and verifying whether it's what you need? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
participants (3)
-
Hartmut Kaiser -
Ovanes Markarian -
Paul Johnson