Closed bradneuman closed 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" }, ...
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)?
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.
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
Sounds good. We could work around it but I think it would be better if xcpretty put the correct base directory in its json.
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
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 incompile_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 inbuild/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 withrtags.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
Your operating system: OS X 10.12.6
LLVM/Clang version: Apple LLVM version 8.1.0 (clang-802.0.42)
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)