Andersbakken / rtags

A client/server indexer for c/c++/objc[++] with integration for Emacs based on clang.
http://www.rtags.net
GNU General Public License v3.0
1.83k stars 252 forks source link

Can't process build from subdirectory #1021

Closed bradneuman closed 7 years ago

bradneuman commented 7 years ago

Please mark appropriate

Problem description

My project builds in a subdirectory, e.g. $ROOT/build/mac where $ROOT is the project root. rtags correctly identifies the project root, but can't handle the include paths in compile_commands.json because they are all relative (e.g. -I../../include)

Expected behavior

I expect rtags to figure out where the build directory is (based on the relative location of compile_commands.json, which is in build/reports currently, but I can move it), or provide me an option to manually set the project root.

Actual behavior

From emacs, no symbols are found, unless they are in the same file. rtags-diagnostics in emacs reports that it can't find the include files in the directory (but the build works normally, of course). Curiously, rtags --check-includes seems to work and prints success (both from the command line and from within emacs), so it's possible this is an issue with rtags.el rather than rtags itself (forgive me, I'm not too experienced with rtags, but I'm eager to get it working). Jumping to a symbol defined in the same file works fine.

I'm currently using xcpretty to generate the compile commands json from an xcode project build. It seems to be working, in the sense that if I copy-paste the commands in the json file into the terminal from the build/mac directory, they compile successfully, but if I try to runt hem from the project root, they fail (with file not found errors). This is why I'm assuming the problem is the relative includes.

Environment

Feature request

I apologize if I'm missing something, but I can't figure out any way to support these relative include paths. Surely this is not the only project that builds inside a subdirectory (although maybe the ../.. include paths are unusual). I can make small changes to the build configuration, but this is a large project with many developers (few of whom use emacs, unfortunately) and a complex build, so I can't go re-organizing the entire thing. Another fix (I'm guessing) would be to be able to manually set the project root directory to be two down from the actual root (but the root is there the highest level .git folder is)

Andersbakken commented 7 years ago

Is there a "directory" entry per file in the json?

That's the one we use for resolving relative paths.

E.g.

... { "directory": "/home/abakken/dev/rtags", <------------ This is used for relative paths "command": "/usr/local/bin/c++ -DCLANG_LIBDIR=/usr/lib/llvm-4.0/lib -DCLANG_VERSION=4.0.0 - DOS_Linux -DRCT_HAVE_OPENSSL -DRCT_HAVE_ZLIB -DRTAGS_SOURCE_DIR=/home/abakken/dev/rtags/src -Isrc -Isrc/rct -Isrc/include -Isrc/selene/include -Isrc/lua-prefix/src/lua-build -Isrc/lua/src -I/usr/lib/llvm-4.0/include -D_GNU_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Wall -Wextra -Wpointer-arith -Wnon-virtual-dtor -Wshadow -Wformat -std=c++11 -pthread -Wstrict-aliasing=2 -Wcast-qual -fPIC -fstack-protector-all -Wstack-protector -O3 -DNDEBUG -ggdb -o src/CMakeFiles/rc.dir/rc.cpp.o -c /home/abakken/dev/rtags/src/rc.cpp", "file": "/home/abakken/dev/rtags/src/rc.cpp" }, ...

bradneuman commented 7 years ago

Ahh, that must be the problem. I have: "directory": "/", so I guess it's looking in the root directory? I suppose this is actually a bug/issue with xcpretty (which generated the json)?

Andersbakken commented 7 years ago

I believe so. I suppose we could work around it by trying multiple paths but I think a little sed-fu on your end might be the more appropriate solution.

bradneuman commented 7 years ago

For posterity: I fixed the issue with the following command: sed -i '' "s_-I../.._-I$PWD/_g" compile_commands.json which replaced the "relative two-directory-up" includes with full paths

Andersbakken commented 7 years ago

Sounds good. We could work around it but I think it would be better if xcpretty put the correct base directory in its json.

bradneuman commented 7 years ago

After a bit more exploration, I think the problem here is that our build system is executing commands with absolute paths (to the executable as well as inputs and outputs), but using a mix of -I directives which are relative and some which are absolute. xcode resolves this, but xcpretty doesn't know how to properly turn this into a compilation command database