CMake project builds fine in command-line, but EasyClangComplete reports errors

[jdumas]

Hi,

So I have a small project with a main.cpp

#include <igl/readOBJ.h>
#include <igl/viewer/Viewer.h>
#include <iostream>

int main(int argc, char * argv[]) {
    using namespace std;
    Eigen::MatrixXd V, TC, N;
    Eigen::MatrixXi F,FTC,FN;
    igl::readOBJ(argv[1],V,TC,N,F,FTC,FN);
    if (FTC.size() == 0) {
        FTC = F;
    }
    igl::viewer::Viewer viewer;
    viewer.data.set_mesh(V,F);
    viewer.data.set_colors((Eigen::MatrixXd(1,3) << 1,1,1).finished());
    viewer.core.is_animating = true;
    viewer.launch();
}

And a CMakeLists.txt that looks like this

CMake_Minimum_Required(VERSION 3.0)
project(example)

# Libigl stuff
Option(LIBIGL_USE_STATIC_LIBRARY "Use LibIGL as static library" OFF)
Option(LIBIGL_WITH_VIEWER      "Use OpenGL viewer"  ON)
Option(LIBIGL_WITH_OPENGL      "Use OpenGL"         ON)
Option(LIBIGL_WITH_GLFW        "Use GLFW"           ON)
Add_Subdirectory("libigl/shared/cmake")

# Target executable
Add_Executable(${PROJECT_NAME} main.cpp ${LIBIGL_EXTRA_SOURCES})
Target_Link_Libraries(${PROJECT_NAME} ${LIBIGL_LIBRARIES} ${LIBIGL_EXTRA_LIBRARIES})
Target_Include_Directories(${PROJECT_NAME} SYSTEM PUBLIC ${LIBIGL_INCLUDE_DIRS})
Target_Compile_Definitions(${PROJECT_NAME} PUBLIC ${LIBIGL_DEFINITIONS})

# Use C++11
Set_Target_Properties(${PROJECT_NAME} PROPERTIES CXX_STANDARD 11)
Set_Target_Properties(${PROJECT_NAME} PROPERTIES CXX_STANDARD_REQUIRED ON)

To compile you need to make a symlink to libigl in the project folder

Now, the project compiles fine in command-line with cmake and make. The .clang_complete file that is generated by EasyClangComplete looks okay, and I am able to compile main.cpp manually (by typing clang++ <flags from .clang_complete> -c main.cpp). However, I am getting a bunch of errors within Sublime given by this plugin, and since the verbose output from the console doesn't show the exact call being made I don't really know what's going on.

Can you reproduce on your side and let me know if I have missed anything?

[niosus]

I think the reason is this:

To compile you need to make a symlink to libigl in the project folder

The project folder is generated automatically in temp folder of the system. This seems to be the issue here. We should discuss how to solve it.

[jdumas]

I just tried with cloning the whole libigl project in the project folder instead of making a symlink, and the problem is the same. Anyway, symlink should behave like normal directories, so CMake or sublime shouldn't even know it's a symlink, unless you test for it explicitly.

[niosus]

Into which project folder did you copy/symlink it? The plugin does not know where is your build directory, it creates it's own one.

[jdumas]

Just create a folder with the following structure:

project/
    main.cpp
    CMakeLists.txt
    libigl/

And while in the project/ directory, clone the libigl library with the following command:

git clone --recursive https://github.com/libigl/libigl.git

Open the folder with sublime:

subl3 .

[niosus]

Ok, I will check back on this issue as soon as I do this. :)

[jdumas]

Sure, let me know if you experience the same behavior as me.

[niosus]

I have cloned the thing and have a project that looks just like yours and everything works for me both with libclang and binary.

If you are using binary completion, search for clang command: The next line is actually the command being run by sublime text.

[jdumas]

Hmm this is weird. Because this is how it looks like for me as soon as I hit the "save" button:

I did not understand what you meant by "If you are using binary completion, search for clang command:"? Autocompletion seems to work fine, but somehow I get these weird errors that you see in the screenshot.

Let me know how if I can be more specific.

[niosus]

Sorry, I should express myself more clearly :) I meant that if you have a setting "verbose": true and "use_libclang": false, the plugin will use clang binary and parse the results with regex. In this case the command that is being issued to clang will be written in the logs in plain text, like this:

DEBUG:EasyClangComplete.plugin.completion.bin_complete: clang command: 
clang++-3.8 -c -fsyntax-only -x c++ -std=c++11 -Xclang -code-completion-at=/tmp/EasyClangComplete/main.cpp:18:10 /tmp/EasyClangComplete/main.cpp -I "/home/igor/Code/test_error" -I "/home/igor/Code/catkin_ws/build/dynamics_processing/src/qt/src" -I "/usr/include" -I "/usr/lib/clang/3.8/include" -I "/home/igor/Code/test_error" -I "/home/igor/Code" -DGLEW_BUILD -I "/home/igor/Code/test_error/libigl/external/nanogui/ext/glew/include" -isystem "/home/igor/Code/test_error/libigl/shared/cmake/../../external/nanogui/ext/eigen" -std=gnu++11 -I "/home/igor/Code/test_error/libigl/external/nanogui/ext/glfw/include" -DGLEW_NO_GLU -isystem "/home/igor/Code/test_error/libigl/shared/cmake/../../external/nanogui/ext/glfw/include" -isystem "/home/igor/Code/test_error/libigl/shared/cmake/../../include" -I "/tmp/EasyClangComplete/cmake_builds/ea53c56c8845f5c7acbd07a2c92a6a3f/libigl/shared/cmake/glfw/src" -I "/home/igor/Code/test_error/libigl/external/nanogui/ext/glfw/src" -isystem "/home/igor/Code/test_error/libigl/shared/cmake/../../external/nanogui/ext/glew/include" -DIGL_NO_MOSEK -D_GLFW_USE_CONFIG_H
DEBUG:EasyClangComplete.plugin.completion.bin_complete: code complete done in 1.1879844665527344 seconds

As you can see clang command: is the log right before the clang command that is being used. You can check that in your system. This full clang command you can just copy into the terminal and check the output for any errors.

I am sorry, but I don't know how to help you more as I cannot reproduce the behavior. The code you gave me builds fine and I see no errors and can autocomplete.

[jdumas]

Ok got it! I already had "verbose": true, but I didn't know about the "use_clang": false. So now that I see the exact command being called, it seems the culprit is that I have a loose -std "=gnu++11" in my .clang_complete file.

Looking at the code there are some differences between the current github version and the one I have on my computer. It looks like the problem was that the flag -std= got separated using the mask {} "{}" no matter what. But looking at the current github code it seems to have been fixed (and indeed when I copy the code from github to my local copy the flag is not separated anymore).

I will let you know if I experience any more trouble.

As a sidenote, I think for complex projects it would really pay off to load the compile_commands.json directly, as it allows to use different flags for different files. I wouldn't mind being able to configure a non-temporary build directory monitored by this plugin (or generated by this plugin). But this has to be non-temporary since header files can be generated in those directories. CLion for example puts those build dirs in ~/.CLion/.... Maybe this is something to think about?

[niosus]

Ah, damn, you're right. I totally forgot to push a new version with the fix to the package control. I will do this today night.

About your side note:

I think for complex projects it would really pay off to load the compile_commands.json directly, as it allows to use different flags for different files.

Feel free to open a separate issue with this suggestion and we can discuss it there.

[jdumas]

Ahah no pb. For the sidenote I'll open a new discussion soon and dump a few ideas I might have.