GNOME Bugzilla – Bug 781354
Treat relative paths from #line directives as being relative to the source file being scanned
Last modified: 2017-06-27 11:26:49 UTC
Created attachment 349894 [details] [review] Patch This fixes an issue when scanning C source code generated by Vala. Such code has lots of #line directives that give just the filename of the C source file. If the g-ir-scanner is was run from the same directory as the source file being scanned then it would calculate an incorrect path for the file, and then ignore all subsequent comments as the incorrect path didn't appear in the file list. (Scanning Vala generated C code isn't necessary in most cases as Vala can output a .gir file itself, but if a single library mixes C and Vala code then you can't use the .gir that Vala generates because it won't include the symbols from the C portion of the library).
(In reply to Sam Thursfield from comment #0) > source file. If the g-ir-scanner is was run from the same directory as "is was" -> "was" :-)
Review of attachment 349894 [details] [review]: Hmm...I'm worried about regressions from this. Have you tested it in e.g. srcdir != builddir configurations? Will CPP emit e.g. #line "../../foo.c" that's not absolute, but we don't want to prefix? Maybe we only do this if the filename doesn't contain `/`?
Good catch. The C preprocessor inserts linemarks of a different form but they are both handled in the same process_linemarks() function of scannerlexer.l. This seems like a bit of a hornet's nest now that I dig deeper... https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html doesn't specify anything about what relative paths in linemarkers should be relative *to*. However, `cpp` clearly expects them to be relative to the build dir. We could mandate that Vala behaves the same, but people like to distribute generated .vala files along with source tarballs, and the #line directives really can't be relative to the builddir in those because we don't know what the builddir *is* at `make dist` time. All I want is to fix introspection for libtracker-sparql which has both C and Vala code. If I can do that another way (perhaps by merging two .gir files into a single .typelib) then I can do without this change anyway.
Knowing the exact project helps, thanks. It *should* work to concatenate the .gir files I think - that seems like a lot less risky fix if we can do that.
We have come up with a different solution for libtracker-sparql in https://bugzilla.gnome.org/show_bug.cgi?id=782091 I'll close this bug for now, feel free to reopen if somebody else needs this change.