Trouble with compilation database

[p-t-g]

First, thanks for irony-mode. It looks like a great package. I am having trouble configuring the compilation database. I've tried to sort it out with no success.

Briefly: Running Emacs 24.3.1. I installed ironyfrom elpa. Then I did M-x irony-install-server and it succeeds.

My source is built outside the source tree. CMake generates the json compilation database in the build directory.

To configure the compilation database, I do M-x irony-cdb-json-add-compile-commands-path RET ~/path/to/source/root RET ~/builddir/compile_commands.json

But it doesn't seem to have any effect, and M-x irony-cdb-menu report "No compilation database in use".

Explicitly doing M-x irony-cdb-autosetup-compile-options RET has no effect.

C-h v irony--compile-options RET says the value is nil.

I'm suspect I'm just doing something wrong ... but I can't figure out what. Any help much appreciated.

[Sarcasm]

Hi,

So it will be a little bit of trials and errors to debug this I think, the way the JSON compilation database is handled may change a little bit in the future.

Can you print me some values:

• C-h v irony-cdb-json--project-alist RET
• M-: (irony-cdb-json--locate-db) RET

And if the last command worked, this one may be big if you compilation database is big:

(irony-cdb-json--load-db (irony-cdb-json--locate-db))

[p-t-g]

Thanks for your quick reply!

The first command produces: (("/workspace/UAToolKit_NEW/Dev/StackWrapper/" . "/Build-Dev/compile_commands.json"))

And the second produces: nil

Of course, the last command does nothing because the location returned is nil, but if I directly enter:

(irony-cdb-json--load-db "~/Build-Dev/compile_commands.json")

it outputs what looks like the contents of the compilation database as a elisp expression.

Cheers,
Patrick

[Sarcasm]

What does the following give you?

• M-: (irony-cdb-json--target-path) RET
• C-h v irony-cdb-json--project-alist RET
• (irony-cdb-json--find-best-prefix-path (irony-cdb-json--target-path) '("~/workspace/UAToolKit_NEW/Dev/StackWrapper/"))

[p-t-g]

I made a mistake in copying paths, so I'll give you everything again to avoid confusion:

Source dir: ~/workspaces/UAToolKit_NEW/Dev/
Build dir: ~/Build-Dev/
cdb location: ~/Build-Dev/compile_commands.json

I do:
M-x irony-cdb-json-add-compile-command-path RET ~/workspaces/UAToolKit_NEW/Dev/ RET ~/Build-Dev/compile-command.json

Results:
C-h v irony-cdb-json--project-alist RET
(("/workspace/UAToolKit_NEW/Dev/" . "/Build-Dev/compile_commands.json"))

M-: (irony-cdb-json--locate-db) RET
nil

M-: (irony-cdb-json--target-path) RET
"/home/patrick/workspace/UAToolKit_NEW/Dev/StackWrapper/Request.cpp" (the file in the current buffer).

C-h v irony-cdb-json--project-alist RET
(("/workspace/UAToolKit_NEW/Dev/" . "/Build-Dev/compile_commands.json"))

M-: (irony-cdb-json--find-best-prefix-path (irony-cdb-json--target-path) '("~/workspace/UAToolKit_NEW/Dev/"))
nil

[Sarcasm]

What about?

M-: (irony-cdb-json--find-best-prefix-path (irony-cdb-json--target-path) '("/home/patrick/workspace/UAToolKit_NEW/Dev/"))

Maybe I'm not expanding the paths every time it's needed.

Can you:

• quit irony/emacs to ensure nothing is cached
• edit ~/.emacs.d/irony/cdb-json-projects by hand, replacing the ~ by /home/patrick.
• Open Emacs/irony and edit Request.cpp to see if the compilation database is found

[p-t-g]

The first command returns /home/patrick/workspace/UAToolKit_NEW/Dev/

Expanding the ~ did the trick! With the ~ expanded manually, the CDB is found and completion works well in .cpp files. It doesn't seem to be working in .h files though. Anything I can do to make it it give sensible results in .h files?

[Sarcasm]

Okay, glad to see that we were able to catch the first issue.

For the second one I'm surprised (how unlucky can you get? :P)

Can you try to evaluate this function which replicate the irony-cdb-json get-compile-options logic:

(defun check-compile-options ()
  (interactive)
  (irony-cdb-json--ensure-project-alist-loaded)
  (irony--aif (irony-cdb-json--locate-db)
      (progn
        (message "I: found compilation database: %s" it)
        (let ((db (irony-cdb-json--load-db it)))
          (irony--aif (irony-cdb-json--exact-flags db)
              (progn
                (message "I: found exact match: %s" it)
                it)
            (let ((dir-cdb (irony-cdb-json--compute-directory-cdb db)))
              (irony--aif (irony-cdb-json--guess-flags dir-cdb)
                  (message "I: found by guessing: %s" it)
                (message "E: guessing failed"))))))
    (message "E: failed to locate compilation database")))

Then in the header file, you can call the function M-x check-compile-options RET.
If you cannot see the messages that are printed you can do C-h e and check the *Message* buffer for relevant output.

[p-t-g]

Thanks again for all your help.

This is what I get from M-x check-compile-options RET.

I: found compilation database: /home/patrick/Build-Dev/compile_commands.json
I: found by guessing: (((-std=c++11 -g -I/home/patrick/workspace/UAToolKit_NEW/Dev/Dependencies/gtest/include -I/home/patrick/workspace/UAToolKit_NEW/Dev/Dependencies/gtest -std=c++11 -Wall -Wshadow -DGTEST_HAS_PTHREAD=1 -fexceptions -Wextra -Wno-unused-parameter -Wno-missing-field-initializers) . /home/patrick/Build-Dev/Dependencies/gtest))

The include paths in particular look incorrect.

[Sarcasm]

So this check-compile-options prints correct flags but irony-cdb-menu says there is no compilation database found? If that so it is weird, because check-compile-options is exactly what the compilation database is doing, with additional debug messages.

[p-t-g]

Sorry. I wasn't clear.

Both check-compile-options and irony-cdb-menu show compile options and they are the same options. The problem is that the settings aren't the correct ones for the header.

[Sarcasm]

Both check-compile-options and irony-cdb-menu show compile options and they are the same options. The problem is that the settings aren't the correct ones for the header.

What do you have VS what do you expect for the compile options?
They are incorrect or simply not the best?

The build system provide no information about the compile option needed for a header file, irony mode has to guess something that will work. The guessing works like this:

We build a compilation database for the directories, as follow:

• for each file in the compilation database, collect the file option per directory
• append the directories found in the compile options -I

With this second, generated compilation database, we look for the best match (longest prefix) for the current buffer.

Not sure if that's clear. What I'm wondering is whether or not your flags are just "too convoluted" or does your header fail to compile/complete?

[p-t-g]

I think the options might be incorrect.

Here's an concreate example using Request.h and Request.cpp in ~/workspaces/UAToolKit_NEW/Dev/StackWrapper/.

check-compile-options for Request.cpp gives:

I: found compilation database: /home/patrick/Build-Dev/compile_commands.json
I: found exact match: (((-DStackWrapper_EXPORTS -DTIXML_USE_STL -std=c++11 -g -fPIC -I/home/patrick/Build-Dev/StackWrapper -I/home/patrick/Build-Dev/StackWrapper/Include -I/home/patrick/Build-Dev/StackWrapper/Matrix -I/home/patrick/workspace/UAToolKit_NEW/Dev/StackWrapper -I/home/patrick/workspace/UAToolKit_NEW/Dev/StackWrapper/Include -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/core -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/proxystub/serverstub -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/proxystub/clientproxy -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/securechannel -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/stackcore -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/transport/tcp -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/transport/http -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/transport/https -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/uastack -I/home/patrick/workspace/UAToolKit_NEW/Dev/AnsiCStack/platforms/linux -I/home/patrick/workspace/UAToolKit_NEW/Dev/GeneralSdk -I/home/patrick/workspace/UAToolKit_NEW/Dev/GeneralSdk/Include -I/home/patrick/workspace/UAToolKit_NEW/Dev/Dependencies/TinyXPath) . /home/patrick/Build-Dev/StackWrapper))

M-x check-compile-options for Request.h gives:
I: found compilation database: /home/patrick/Build-Dev/compile_commands.json
I: found by guessing: (((-std=c++11 -g -I/home/patrick/workspace/UAToolKit_NEW/Dev/Dependencies/gtest/include -I/home/patrick/workspace/UAToolKit_NEW/Dev/Dependencies/gtest -std=c++11 -Wall -Wshadow -DGTEST_HAS_PTHREAD=1 -fexceptions -Wextra -Wno-unused-parameter -Wno-missing-field-initializers) . /home/patrick/Build-Dev/Dependencies/gtest))

To understand Request.h, libclang is going to need most of the same -I options as Request.cpp, but they are missing.

Thanks for your help!

[Sarcasm]

Sorry for the delay.

It is weird indeed, something is off in the guessing mechanism I guess.

Would you be able to find which file uses these gtest flags in the compilation database and print the entry?

If you are not familiar with elisp, the most helpful for debugging would be to provide a reduced test case if you can but I would understand if that's not easy to do.

While waiting for this bug to be fixed you can still create a .clang_complete file with the proper flags.

[p-t-g]

On 20/04/2015 3:04 PM, Guillaume Papin wrote:

Sorry for the delay.

It is weird indeed, something is off in the guessing mechanism I guess.

Would you be able to find which file uses these gtest flags in the
compilation database and print the entry?

If you are not familiar with elisp, the most helpful for debugging
would be to provide a reduced test case if you can but I would
understand if that's not easy to do.

While waiting for this bug to be fixed you can still create a
|.clang_complete| file with the proper flags.

—
Reply to this email directly or view it on GitHub
#190 (comment).

No worries. Thanks for your help. Even with these glitches irony is great.

I'm not familiar with elisp, but I know scheme. When I get a chance I'll
try to do some debugging and/or create a simpler test case.

Thanks again.