-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Follow symbolic links for filename comparison #542
Conversation
I'm pretty sure I used to do a lot (expansive?) file-truename in the past, but it did not handle the case where the symbolic name was important. We could fix it, but I think the libclang backend already solve this by using something like |
First time user so could be I'm just confused. What I was seeing was the source filename in the get-compile-options query was not being stripped off after the query. irony-cdb-libclang--adjust-options-and-remove-compiler is calling into the irony-cdb-json--adjust-compile-options to parse the response so I think both backends are using the same code to parse the compiler options? |
Oh I see, it's me that was no longer familiar with the code, sorry about that. What issue did you notice with the filename being here? Sorry for being wary about this change, but it adds a syscall (or way more, looking at the implementation) for each argument of the command, so I'm a bit reluctant. |
No problem with being leery of adding overheads. Maybe problem lies more with how the compile_commands.json filenames I'm getting? The project is using Waf for configure/build which is not all that common. Comparing with a cmake generated file I notice the filenames are absolute in cmake and relative from Waf. The Waf build directory is the true path, the src filenames are relative. Is it expected that paths be absolute in the compiler commands? First time I've used this file. Waf generated { Cmake generated { |
It's not required for the paths to be absolute, but I'm pretty sure I encountered an issue a while back in a clang tools, might have been fixed since then. What I'm wondering is what error did you notice? |
Thanks for the help. The real core of my issue, as far as I can debug, originates from the compile_commands.json having different paths in it (real path) vs editing in the context of a soft link path. The error is:
Looking at the log file, the src file is being included in the complete instead of being stripped off.
Manually executing the get-compiler-options through the irony server, the returned data has the true paths in it.
|
Ok thank you, so I guess libclang does not filter-out the sources itself, even though we specify the source file to process, and also, the file in the command line should be compatible... Just to limit the impact of the change, I think we can do 2 things:
|
I pushed up a change. Wasn't super sure best place to put the "-" skipping, inline with the file check or adding an additional skip cond before the file check. Intent seemed a less order dependent and clear to me adding an AND to file cond. |
Great! Thank you for your patience. |
Release 1.4.0 In this release: - cache compilation database [SarcasmGH-499] - add support for new libclang versions, which should now support newer versions automatically - CMake modernization, require CMake >= 3 - improved compile options adjustement [SarcasmGH-542]
In a src tree with several symbolic links in paths the filenames did not always match. At least with the waf build tool the real path name is appearing in the compile_commands.json file. The compiler option parsing was failing to remove the src file. Used file-truefilename to follow symbolic links for name comparison.