atilaneves / cmake-ide Goto Github PK

First of all, I like your solution a lot and it's really nice being able to auto-complete and flycheck my fairly large work projects with cmake-ide now. I tried so many different things before..

One thing I noticed is that in cmake-ide-setup you use c-mode-common-hook, which should be fine but there are some major modes that derive from c-mode, like php-mode, but it's not expected behavior that it also tries to find/run cmake and setting flags for those files.

Perhaps an optional list of modes could be supplied to cmake-ide-setup so that it only hooks up to those, and if nothing is given then it uses c-mode-common-hook as it does now?

I get that error when trying to run cmake-ide-run-cmake

I'm managing rdm via systemd, so it's running, but cmake-ide checks if (get-process "rdm") returns true and if not, starts rdm itself. It always seems to evaluate to false, and so starts it itself, even though I'm running rdm as user. The original rdm from systemd then seems to shutdown, leaving me without an rdm once I close emacs since rdm is a child process of emacs when cmake-ide launches it.

I don't know if there's a function similar to get-process that can see outside of the emacs process tree (if that's what the problem is). Doing (shell-command "pgrep rdm") seems to have its indented effect on my end, but I don't know if that's desirable.

Some of my files have different extensions, e.g.

.cu

It would be good to have the list of source file extensions in a file

current impl:

(defun cmake-ide--is-src-file (string)
  "Test if STRING is a source file or not."
  (or (cmake-ide--ends-with string ".c")
      (cmake-ide--ends-with string ".cpp")
      (cmake-ide--ends-with string ".C")
      (cmake-ide--ends-with string ".cxx")
      (cmake-ide--ends-with string ".cc")))

Hello!

In my quest to research how effective emacs can be as a c++ ide, I have come across this repo. I am working in an environment where clang is not available, so my first question is whether there is any problem or limitation with using GCC/G++ instead of clang?

My next question is about the architecture of cmake-ide: how does this setup compare or overlap with the functionality outlined in these many videos about using emacs for c++:

https://www.youtube.com/watch?v=HTUE03LnaXA

The packages used in those videos are: http://barisyuksel.com/cppmode/package_versions.png

There are so many packages out there and I'm not an emacs expert, but I do know that many different packages tend to compete with each other for functionality. Does the cmake-ide solution bundle together the functionality mentioned in these other packages/videos?

Many thanks!

This is not really issue-worthy, but I don't really see how to tackle this. cmake-ide is working fine so far, but my autocompletion (with auto-complete) is quite bland, there's no method signature for example, only the name of the function.

How do you get function signature for your autocompletion, using cmake-ide ? (similar to what was shown on your presentation)

CMake allows users to define SYSTEM include paths (this are include paths for which include files will not give warnings when compiled). This include paths are passed as an option with "-isystem path" as you can see in the following example compile_commands.json.

    [
    {
      "directory": "/home/vseguip/Proyectos/modmsb/build/src",
      "command": "/usr/bin/c++   -Dmodmsb_EXPORTS -D_REENTRANT -fPIC  -isystem /home/vseguip/Proyectos/xld_extensions-9.0/include -isystem /home/vseguip/Proyectos/xld_extensions-9.0/include/cpp -I/usr/include/nptl -I/home/vseguip/Proyectos/modmsb/src/include -I/usr/include/picvisa    -W -Wall -Wshadow -fvisibility=hidden -o CMakeFiles/modmsb.dir/msb.cpp.o -c /home/vseguip/Proyectos/modmsb/src/msb.cpp",
      "file": "/home/vseguip/Proyectos/modmsb/src/msb.cpp"
    },
    {
      "directory": "/home/vseguip/Proyectos/modmsb/build/src",
      "command": "/usr/bin/c++   -Dmodmsb_EXPORTS -D_REENTRANT -fPIC-isystem /home/vseguip/Proyectos/xld_extensions-9.0/include -isystem /home/vseguip/Proyectos/xld_extensions-9.0/include/cpp -I/usr/include/nptl -I/home/vseguip/Proyectos/modmsb/src/include -I/usr/include/picvisa    -W -Wall -Wshadow -fvisibility=hidden -o CMakeFiles/modmsb.dir/modmsb.cpp.o -c /home/vseguip/Proyectos/modmsb/src/modmsb.cpp",
      "file": "/home/vseguip/Proyectos/modmsb/src/modmsb.cpp"
    }
    ]

This "-isystem" include paths should be passed along to flycheck so it inivokes the clang compiler with them but currently are not. I've got a dirty hack in cmake-ide to make it working, however I don't think it integrates very well with it. If you like I can issue a pull request.

A lot of developers have migrated from autocomplete to company mode as well as clang completions to irony mode. Personally I use :

• Irony Mode
• Company Irony
• Company Irony C headers
• Flycheck Irony
• Irony-eldoc

Irony mode works with libclang, sends to company irony which also works in completing c headers. Then Irony mode works with flycheck for diagnostics. Eldoc is different thing.

It looks like there's an implied package dependency from the use of some in cmake-ide--is-src-file. What package does this come from?

The function cmake-ide--get-existing-definitions returns the value of the variable cmake-ide-definitions but this is the only place this variable exist, so it will be always nil. It is some kind of legacy code?

Got a new error with the latest melpa version (20160106.101),
seems to have an unmatched parenthesis in "cmake-ide.el", line 342

Whenever I enter some buffer that is a hpp file and not a cpp, cmake-ide seems to set wrong flags to rtags and flycheck.

Both stop working, but flycheck gives me errors like:
clang: error: no such file or directory: 'CMakeFiles/Evaluation.dir/src/Measures/BoundaryPrecision.cpp.o'

The problem, as far as I understand, is that whenever the file cmake-ide is setting the flags is a header file, it will simply include all the possible .o files of the project to it, and since these files haven't been compiled yet, they doesn't exist and so I get the error.

I guess a cmake-ide-compile would generate the .o files, but it is a little cumbersome to do it every time I open the project or create a new file in it.

And even with cmake-ide-compile, the problem persists whenever I have a add_subdirectory command, for example, in my project, the root CMakeLists.txt have this:
add_subdirectory (libs)

Inside the libs directory, exists another CMakeLists.txt, this one contains:
add_subdirectory (Evaluation)

And inside Evaluation I have a new project which will generate a evaluation lib with add_library that is used in my root project.

The problem in this case is that cmake-ide seems to ignore this directory structure, in the error example:
clang: error: no such file or directory: 'CMakeFiles/Evaluation.dir/src/Measures/BoundaryPrecision.cpp.o'

the path is incorrect, the correct one is:
libs/Evaluation/CMakeFiles/Evaluation.dir/src/Measures/BoundaryPrecision.cpp.o
inside the temporary directory:
/tmp/cmake8265867v

If you can't reproduce this, I can create a small cmake project with the problem to send to you, but it should fire with any add_subdirectory in CMakeLists.txt

It may be a useful enhancement to allow users to have a variable to set options to cmake in cmake-ide--run-cmake-impl. One use case is a Android CMake project (android-cmake) which requires specifying the Android toolchain as a -D option which cannot be placed in the CMakeLists.txt file eg:

cmake -DCMAKE_TOOLCHAIN_FILE=../android-cmake/android.toolchain.cmake -DANDROID_NDK=/opt/android-ndk-r10e -DCMAKE_BUILD_TYPE=Release -DANDROID_ABI="armeabi-v7a with NEON" -DANDROID_NATIVE_API_LEVEL="android-21" ..

The rest of the flags other than CMAKE_TOOLCHAIN_FILE can probably be specified in the CMakeLists.txt file, but CMAKE_TOOLCHAIN_FILE must be specified as a cmake option.

As a workaround its obviously easy to edit cmake-ide--run-cmake-impl.

We have a project that looks something like this:

product/CMakeLists.txt
product/daemon/CMakeLists.txt
product/daemon/src/CMakeLists.txt
product/daemon/tests/CMakeLists.txt
product/monitor/CMakeLists.txt
product/ui/CMakeLists.txt

When we open a file that is in product/daemon/src, it appears to be using all the -I options, -include options, etc. for all projects that life under the product directory (all those listed above), instead of just those generated by the inclusion of the CMakeLists files that lead back to the root (the ones in product, product/daemon, and product/daemon/src).

You can see an example of this in my other issue, #24.

I've tried creating a .dir-locals.el in the product/daemon/src directory that points to either the CMakeLists.txt file in product/daemon/src, or to the one in /product, but the result is the same:

((nil . (
     (cmake-ide-dir . "/Users/stebro/product/daemon/src")
         )))

Is there some other way I'm supposed to configure things to see only the relevant CMakeLists.txt files in a project?

Since searching for the source file for a header is unusably slow for me, I disabled it:

(setq cmake-ide-header-search-other-file nil)
(setq cmake-ide-header-search-first-including nil)

But it still takes several seconds to open a header file, much longer than a source file.

Here's output from the profiler:

profiler.txt

compile_commands.json is 5-6 MB for my project (which is proprietary, so I can't link it)

cmake-ide overrides the flycheck-clang-definitions. But I need to provide an extra define to flycheck for it to be able to check my code.

Can you add an option for this, similar to cmake-ide-flags-c?

Hello

this is what I have in my .emacs

(setq cmake-ide-flags-c++ "-I/usr/local/include -I/usr/include -I/home/hich/dir1")
(setq cmake-ide-dir "/home/hich/dir1-release")
(require 'rtags) ;; optional, must have rtags installed
(setq rtags-rdm-includes "/usr/lib/gcc/x86_64-redhat-linux/5.1.1/include/")
(cmake-ide-setup)

However, in the rdm buffer, I see the following:

Running with 2 jobs, using args: -ferror-limit=0 -Wall -fspell-checking -Wno-unknown-warning-option
Includepaths: -isystem /usr/lib64/llvm/clang/3.5.0/include/

this directory doesn't even exit.

How is it that cmake-ide calls rdw with that path?

Perhaps you forgot to add it to your dependencies? Not sure.

I saw your CppCon talk and I remembered that I have tried cmake-ide before, but with limited success because I have not used Emacs packages before and have not done much Lisp.

However, I would really like to get it up and running so a Wiki page guiding some one and actually talking about a few gotchas would be immensely helpful!

I could work with you to create something like this if you don't have enough time but the patience to answer my stupid questions.

This is an enhancement.

Seeing the following error in .h file when it tries to autocomplete (the error seems coming from company-mode):

Suspicious state from syntax checker c/c++-clang: Checker c/c++-clang returned non-zero exit code 1, but no errors from output: error: invalid argument '-std=c++11' not allowed with 'C/ObjC'

If I change the file to .hh instead of .h, the error goes away, and the behavior is back.

Thanks for looking into this.

Would it be possible to:

• put the source file detection into an async thread,
• cache the information?

The delay when opening a file is quite annoying.

I am using cmake-ide in a c++11 project and flycheck is giving me lots of errors. I run flycheck-compile with c/c++-clang and I was able to see that the argument -std=c++11 was missing. I copied the exact line and executed from the console passing this parameter and it reported no errors. I review a little the code of cmake-ide and I found that the only parameters that are captured are the includes -I, -include, -isystem and the definitions -D. I think that there are lots of other parameters that are importan to pass to the compiler such us: -std, the -f* and the -W*.

I have a project that uses -std=c++14. flycheck (with cmake-ide) marks all C++14 additions as errors. When I manually set the variable flycheck-clang-language-standard to the string "c++14", it works. Since being as 0-config as possible as one of the goals of cmake-ide, maybe we can get rid of this manual setup step, too?

Our compile line is specifying environment variables which are quoted strings containing spaces. When flycheck is trying to compile the file, the options are not being correctly handled, resulting in errors like:

In file included from <built-in>:346:
<command line>:4:23: warning: missing terminating '"' character

Example (note the value specified for DPRODVER_STRING):

Actual compilation line for translation unit:

cd \
  /Users/stebro/product/daemon/build_debug/src \
  && \
  /usr/bin/clang++ \
  -DASSERT_ON \
  -DPRODVER_BUILD_NO=999 \
  -DPRODVER_FULL=\"99.9.999\" \
  -DPRODVER_MAJOR=99 \
  -DPRODVER_MINOR=9 \
  -DPRODVER_STRING="\"99.9.9d1 build 999 (2008-01-01 12:00:00)\"" \
  -DQT_CORE_LIB \
  -DQT_NETWORK_LIB \
  -D_DEBUG=1 \
  -g \
  -arch \
  i386 \
  -isysroot \
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk \
  -mmacosx-version-min=10.7 \
  -I/Users/stebro/product/daemon/build_debug/src \
  -I/Users/stebro/product/daemon/src \
  -isystem \
  /Volumes/ProductToolChain/include \
  -isystem \
  /Volumes/ProductToolChain/include/log4qt \
  -isystem \
  /Volumes/ProductToolChain/include/log4qt/varia \
  -I/Users/stebro/product/daemon/src/../include \
  -I/Users/stebro/product/daemon/dbcommon/include \
  -F/Volumes/ProductToolChain/qt-5.5/lib \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers \
  -I/Volumes/ProductToolChain/qt-5.5/mkspecs/macx-clang-32 \
  -I/Users/stebro/product/daemon/dbcommon/ClientShared/include \
  -I/Users/stebro/product/daemon/build_debug/dbcommon/ClientShared/include \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtNetwork.framework/Headers \
  -stdlib=libstdc++ \
  -Werror \
  -Wno-c99-extensions \
  -Wno-c++98-compat \
  -Wreorder \
  -Wunused-variable \
  -Woverloaded-virtual \
  -Wno-unused-local-typedef \
  -Wno-inconsistent-missing-override \
  -Wunused-function \
  -Wno-unknown-warning-option \
  -Wno-#warnings \
  -Wno-c++11-extensions \
  -Wshorten-64-to-32 \
  -Winvalid-pch \
  -fPIC \
  -o \
  CMakeFiles/Client.dir/services/scan/VolumeChangeMonitor.cpp.o \
  -c \
  /Users/stebro/product/daemon/src/services/scan/VolumeChangeMonitor.cpp

Compile line used by flycheck-compile:

clang \
  -fsyntax-only \
  -fno-color-diagnostics \
  -fno-caret-diagnostics \
  -fno-diagnostics-show-option \
  -iquote \
  /Users/stebro/product/daemon/src/services/scan/ \
  -std\=c\+\+1y \
  -Wall \
  -Wextra \
  -DDBCOMMON_EXPORTS \
  -DLOG4QT \
  -DPRODVER_BUILD_NO\=999 \
  -DPRODVER_FULL\=\\\"99.9.999\\\" \
  -DPRODVER_MAJOR\=99 \
  -DPRODVER_MINOR\=9 \
  -DPRODVER_STRING\=\"\\\"99.9.9d1 \
  -DQT_CORE_LIB \
  -DQT_NO_DEBUG \
  -DQT_NETWORK_LIB \
  -DASSERT_ON \
  -DUNIT_TESTING \
  -D_XCODE \
  -DQT_GUI_LIB \
  -DQT_WIDGETS_LIB \
  -DQT_PRINTSUPPORT_LIB \
  -DQT_TESTLIB_LIB \
  -I/Volumes/ProductToolChain/include/log4qt/varia \
  -I/Volumes/ProductToolChain/include/log4qt \
  -I/Volumes/ProductToolChain/include \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/src \
  -I/Users/stebro/product/daemon/dbcommon/src \
  -I/Users/stebro/product/daemon/dbcommon/include \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers \
  -I/Volumes/ProductToolChain/qt-5.5/mkspecs/macx-clang-32 \
  -I/Users/stebro/product/daemon/dbcommon/ClientShared/include \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/ClientShared/include \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/test \
  -I/Users/stebro/product/daemon/dbcommon/test \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/tools-convert/convertstatus \
  -I/Users/stebro/product/daemon/dbcommon/tools-convert/convertstatus \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/ClientShared/src \
  -I/Users/stebro/product/daemon/dbcommon/ClientShared/src \
  -I/Users/stebro/product/daemon/dbcommon/ClientShared/include/QsLog \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtNetwork.framework/Headers \
  -I/Users/stebro/product/daemon/src/daemon/dbcommon/ClientShared/test \
  -I/Users/stebro/product/daemon/dbcommon/ClientShared/test \
  -I/Users/stebro/product/daemon/src/daemon/src \
  -I/Users/stebro/product/daemon/src \
  -I/Users/stebro/product/daemon/src/../include \
  -I/Users/stebro/product/daemon/src/daemon/tests \
  -I/Users/stebro/product/daemon/tests \
  -I/Users/stebro/product/daemon/src/ui/common \
  -I/Users/stebro/product/ui/common \
  -I/Users/stebro/product/ui \
  -I/Users/stebro/product/ui/common/ui \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtGui.framework/Headers \
  -I/System/Library/Frameworks/OpenGL.framework/Headers \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtWidgets.framework/Headers \
  -I/Users/stebro/product/daemon/src/ui/status \
  -I/Users/stebro/product/ui/status \
  -I/Users/stebro/product/daemon/src/ui/install \
  -I/Users/stebro/product/ui/install \
  -I/Users/stebro/product/ui/install/ui \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtPrintSupport.framework/Headers \
  -I/Users/stebro/product/daemon/src/ui/helpers/install \
  -I/Users/stebro/product/ui/helpers/install \
  -I/Users/stebro/product/daemon/src/ui/ui \
  -I/Users/stebro/product/ui/ui \
  -I/Users/stebro/product/ui/ui/../ui \
  -I/Users/stebro/product/daemon/src/ui/tests \
  -I/Users/stebro/product/ui/tests \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtTest.framework/Headers \
  -x c\+\+ \
  - < /Users/stebro/product/daemon/src/services/scan/VolumeChangeMonitor.cpp

I'm using cmake-ide with rtage and have a project which generates a large (159M) compile_commands.json file. This seems to be the cause of a minute-plus long delay when opening a new file. Most of the cpu usage is in cmake-ide--on-cmake-finish, and inside of it, most of the work is in json-read-file and the delete-dups inside of cmake-ide--commands-to-hdr-flags.

Is there anything I can do to mitigate the performance problem?

Failing that, I thought I'd bring the issue to your attention.

Hello there,

cmake-ide uses the compile_commands.json file to grab the project files compiler flags, but since this file doesn't show any information about the compiler flags of header files, we need to try finding it with some hacky way (like find a source file with the same name and using it's compiler flags), this works in simple projects, but in anything more complex, problems will arise.

I've made some simple changes to the cmake's project source code so it will insert header information in the compile_commands.json file too, (you obviously need to list the headers files in the CMakeLists.txt file, for example add_executable(project main.cpp test.cpp test.hpp)), but it doesn't seems like it will be accepted mainstream (you can see my bug report here bug report link maybe you can help me convince the cmake devs that there is people interested in this feature.

Regardless of that, one already built-in solution in cmake is to use the CodeBlocks generator file instead of the compile_commands.json since that one will show all the information about every file you listed in your CMakeLists.txt file, including headers.

The problem is that this format is not as straight forward as the compile_command.json since it needs a little bit more logic to grab all the compiler flags information. But since this will give all the information we need without relying in hacks and always work despite the project size or complexity, maybe is a great alternative to make emacs works better as a real IDE.

Hi,

Seems very promising project. I've been looking for a C++ development environment for Emacs: cpputils-cmake, irony-mode, etc. Not easy to install, not easy to configure or make it work when you test on your project instead of a dumb and merely example with 2 unit compilation files and 3 headers.

JSON Compilation Database file is the way to go and I think you're right to use it. I recently switched to company from auto-complete and I'm quite satisfied.

A support for company would be great !

Thanks,
Damien

I have a OSX project that is using an IDL to generate cpp & h files in my build space (Google's grpc). Using cmake-ide with the default configuration results in the compile-commands.json being generated in the /tmp directory, which of course doesn't have the generated files in it (since make hasn't been run in that space).

I tried setting cmake-ide-build-dir to my build directory (located in /Users/stebro/MyProject/build), and I see in the cmake buffer that it is using that directory, but no compile-commands.json is generated in that space, likely because we're using XCode as our build system, so there is no Makefile in that directory, just XCode project files.

I also tried setting cmake-ide-flags-c++ to ""-I/Users/stebro/MyProject/build/lib/Debug/include -I/Users/stebro/MyProject/build/Daemon/RemoteClient" (the two include paths that have the generated header files), but apparently that variable is not passed into rtags/rdm (the cmake-ide docs do say that it's only used by ac-clang-flags).

What's the best approach to getting rtags/rdm to see include in the build space of your project?

I keep on seeing this message. Don't know if it is a warning or not.

cmake-ide [Mon Jun 27 19:19:27 2016]: Could not find suitable src file for /path/to/header.h, using all compiler flags

Not exactly sure what it means. It suggests every header file opened tries to look for a similarly named src file. I have the cmake-ide-header-search-other-file set to nil but not sure if related.

               (setq cmake-ide-header-search-other-file nil
                     cmake-ide-header-search-first-including nil
                     cmake-ide-try-unique-compiler-flags-for-headers nil)

Should I worry about the message above? Opening files with rtags is not very fast on my 4MB compile_commands.jsonfile so I am trying to find as much time as possible,

This is listed on Melpa but when trying to install, it says the package is unavailable.

I tried to simply download and load the cmake-ide.el myself, but then it says the file or directory "levenshtein" is not available.

Can you assist with this installation query? Many thanks!

Also, is rtags necessary for the autocompletion?

When cmake-ide fails to find the corresponding cpp file for a header, it includes everything to the hdr-flags variable.

But sometime this is not the best approach since it can lead to false-negatives of flycheck.

This can happen when your cmake project contains subprojects (added by add_subdirectory).

For example, you have a project with 2 subprojects, subproj1 and subproj2.

Now, subproj2 have a dependecy with libxml, so when you open a cpp file of subproj2, compile_commands.json will have the necessary includes to libxml in it.

Now, let's say you open a hpp file of subproj1 and add a #include <libxml/libxml.h> to it, since subproj1 doesn't have a dependency with libxml, it will fail to find this header and fail in compilation.

But since cmake-ide will add all the possible includes, it will include the libxml include path to it and flycheck will think that the #include above is ok and not a error.

Now, for the solution, I think we can use the directory information from compile_commands.json, as far as I understand it, this parameter will show the root of the project in it, for example, let's say I have a file test.cpp in subproj2, with this path /project/subproj2/src/Tests/test.cpp, in the json file, the directory parameter for this file will be:
"directory" : "/tmp/cmakef2342e32e32/subproj2"

Actually, every file in subproj2 will have this same directory, and files of subproj1 will have the path to subproj1.

The idea is to group the includes based in this directory parameter, what cmake can do is create an map of all the flags of all files for each subproject, and when a file is opened, it will see if the file is inside some subproject and only use their flags, so, for example, if I opened a file Test.hpp located in /project/subproj2/includes/Tests/test.hpp", cmake-ide will see that this file is inside the subproj2 directory and so it belongs to subproj2, and as consequence will set all flags of subproj2 (but will not set the flags of subproj1).

Do you think this is a good solution for this? And a easy one to implement?

Thanks

use case: cmake script tries to find dependencies via non-environment variables

can be worked around by pre-running cmake with parameters so that they are cached for the parameter-less invocation by cmake-ide

I got problems with compile_commands.json which contains relative paths to include directories.
Here is the part of my file which was generated with -GNinja option:

{
  "directory": "/Users/user/dev/project/build",
  "command": "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc  -DHAVE_CONFIG_H -DHTTP_PARSER_STRICT -DLUASOCKET_DEBUG -DWITH_COMPAT -DWITH_DOM -DWITH_NOIO -DWITH_OPENSSL -D_REENTRANT -I/usr/local/include -I/usr/local/include/luajit-2.0 -Ijansson-2.7/include -I/usr/local/opt/openssl/include -I/usr/local/include/mysql -I. -I../libs -I../libs/gsoap -I../libs/http-parser -I../libs/uthash -I../src -I../src/onvif -I../tests -I../src/ddutil/src -I../src/ddutil/src/lua/socket -I../src/ddutil/libs -I../src/ddutil/libs/uthash -Iddutil  -Wall -pedantic -O2 -O3 -DNDEBUG   -o src/ddutil/src/lua/socket/CMakeFiles/LUASOCKET_FILES.dir/options.c.o   -c /Users/user/dev/project/src/ddutil/src/lua/socket/options.c",
  "file": "/Users/user/dev/project/src/ddutil/src/lua/socket/options.c"
}

As you can see we got relative include dirs like -I../libs/http-parser, etc.
Here is what I got from emacs:

flycheck-clang-include-path is a variable defined in `flycheck.el'.
Its value is
("/usr/local/include" "/usr/local/include/luajit-2.0" "jansson-2.7/include" "/usr/local/opt/openssl/include" "/usr/local/include/mysql" "." "../libs" "../libs/gsoap" "../libs/http-parser" "../libs/uthash" "../src" "../src/onvif" "../tests")

The current directory unfortunately not /Users/user/dev/project/build, so with these relative paths flycheck is unable to locate correct include dirs and gives warnings.

Thanks.

Is it possible to add cmake-ide-may-load-db only if the DB has changed? Or is this how cmake-ide-load-db already works?

This would allow to hook up the loading of the DB when a c++-mode file is opened but only if the compile_commands.json has changed since the last time the file was opened.

An alternative would be to provide an API to check if the DB has changed and leave the client with the decision to load or not to load the DB.

Should cmake-ide-clang-flags-c or cmake-ide-flags-c++ be set even though CMakeLists.txt has set(CMAKE_CXX_FLAGS "-std=c++11")?

Should this not be picked up from compile_commands.json's "command": "/usr/bin/c++ -std=c++11 ... ?

Or is my config wrong?

flycheck and rtags are loaded before the cmake-ide.

After installing CMake IDE by means of the package manager, the README, TODO and LICENSE are not present in the package directory.

Thanks for your attention and for sharing this useful package.

I am having problems reading the compile_commands.json file. The compile command includes -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-istl which is read as -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dunestl (note the missing dune-istl has been read as dunestl near the end).

For example:

[
{
  "directory": "/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/build-clang/dune-evolving-domains/src",
  "command": "/home/csunix/scstr/Software/anaconda/bin/clang++   -DENABLE_MPI=1 -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX -DMPIPP_H -O3 -Wall -Wno-unused-parameter -std=c++11  -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/build-clang/dune-evolving-domains -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains -I/usr/include/openmpi-x86_64 -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-common -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-geometry -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-grid -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-localfunctions -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-istl -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-alugrid -I/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-fem    -o CMakeFiles/dune_evolving_domains.dir/dune_evolving_domains.cc.o -c /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains/src/dune_evolving_domains.cc",
  "file": "/home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains/src/dune_evolving_domains.cc"
}
]

is read to give so that the output of flycheck-compile on dune_evolving_domains.cc as

clang -fsyntax-only -fno-color-diagnostics -fno-caret-diagnostics -fno-diagnostics-show-option -iquote /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains/src/ -std\=c\+\+11 -Wall -Wextra -DENABLE_MPI\=1 -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX -DMPIPP_H -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/build-clang/dune-evolving-domains -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains -I /usr/include/openmpi-x86_64 -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-common -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-geometry -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-grid -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-localfunctions -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dunestl -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-alugrid -I /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-fem -O3 -Wall -Wno-unused-parameter -o CMakeFiles/dune_evolving_domains.dir/dune_evolving_domains.cc.o -c -x c\+\+ - < /home/cserv1_a/soc_staff/scstr/Software/DUNE/dune-2.4/dune-evolving-domains/src/dune_evolving_domains.cc

This is with GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.14.13) of 2016-01-04 on CentOS Linux release 7.2.1511 (Core).

Any help is appreciated.

The actual compilation line for a file (I can provide a self-contained cmake project for this issue, if necessary):

/usr/bin/clang++ \
  -DDBUTIL_EXPORTS \
  -DQT_CORE_LIB \
  -DQT_NO_DEBUG \
  -isysroot \
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk \
  -mmacosx-version-min=10.7 \
  -fPIC \
  -I/Users/stebro/test/sqlite/include \
  -I/usr/local/include \
  -F/Volumes/ProductToolChain/qt-5.5/lib \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers \
  -I/Volumes/ProductToolChain/qt-5.5/mkspecs/macx-clang-32 \
  -fPIC \
  -E \
  -c \
  /Users/stebro/test/sqlite/DBQuery.cpp

The line being used by flycheck, after cmake-ide initalization:

clang \
  -fsyntax-only \
  -fno-color-diagnostics \
  -fno-caret-diagnostics \
  -fno-diagnostics-show-option \
  -iquote \
  /Users/stebro/test/sqlite/ \
  -std\=c\+\+1y \
  -Wall \
  -Wextra \
  -DDBUTIL_EXPORTS \
  -DQT_CORE_LIB \
  -DQT_NO_DEBUG \
  -I/Volumes/ProductToolChain/qt-5.5/mkspecs/macx-clang-32 \
  -I/Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers \
  -I/Users/stebro/test/sqlite/include \
  -I/usr/local/include \
  -x c\+\+ \
  - < /Users/stebro/test/sqlite/DBQuery.cpp

The lack of the -F option is producing the error:

In file included from <stdin>:8:
In file included from /Users/stebro/test/sqlite/DBQuery.h:11:
In file included from /Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers/QVector:1:
/Volumes/ProductToolChain/qt-5.5/lib/QtCore.framework/Headers/qvector.h:37:10: fatal error: 'QtCore/qalgorithms.h' file not found

The environment that I work in uses a wrapper python script to launch cmake (to setup the compiler environment first before running cmake). It would be nice to be able to set a variable, cmake-ide-cmake-command, or something like that (but defaults to cmake), so that there is some customization as to how cmake is run.

It's hard to remove hook functions that are lambdas because you can't do (remove-hook 'before-save-hook 'name-of-hook-function).

I have a weird problem with this variable. Say I try to set up my project with existing source and CMakeFiles.txt for the first time. First of all I leave this variable empty and run cmake-ide-run-cmake. Then everything works. From the RDM log, I can see rtags was indexing my project.

However, if I set the cmake-ide-dir variable first, then run cmake-ide-run-cmake, rtags will not index my project at all? Is this a bug or I have to run the command without setting up this variable for the very first time for each project?

I am trying to set the -Isystem flag of flycheck-clang-args in my .dir-locals.el as so:

((c++-mode . ((flycheck-clang-args . ("-isystem/path/to/3rd-party-libs/include")))))

When cmake-ide is running, flycheck-clang-args is overwritten so this has no effect. I also tried setting -Isystem with the cmake-ide-flags-c++ variable instead. However, from reading the cmake-ide.el file it appears that the -I flags are filtered out?

I want to be able to do this so that flycheck-clang will ignore the errors for the third party libraries that I specify. Otherwise, I see errors at the #include lines for the third party library headers. Alternative solutions are welcome.

Thanks.

How about cmake-ide comparing to cpputils-cmake?

CMake-ide uses ff-find-other-file to find the cpp file of a header, but in my project it always fails to find and in the end include all the flags of the project.

the problem is that this search locks emacs for almost 4 seconds, so every time I open a hpp now it locks emacs for this period.

cmake-ide will always use the default compiler set in environment CC and CXX variables, normally this will mean gcc.

It would be better if cmake-ide allowed the user to be able to change it to another compiler, say clang for example, without changing the CC and CXX variables.

The reason for that is when your project have precompiled headers (use cotire for example), irony syntax checker will fail since it will try to use the specific compiled files for gcc (the normally default compiler) with clang (see this issue for more about it: Sarcasm/irony-mode#277 ).

The fix seems easy enough, with this simple change I can make cmake-ide always use clang:
Change
(start-process cmake-ide-cmake-command "cmake" "cmake" "-DCMAKE_EXPORT_COMPILE_COMMANDS=ON" project-dir))))
to
(start-process cmake-ide-cmake-command "cmake" "env" "CC=clang-3.6" "CXX=clang-3.6" "cmake" "-DCMAKE_EXPORT_COMPILE_COMMANDS=ON" project-dir))))
in the cmake-ide--run-cmake-impl function.

Sure, the actual fix should permit changing to whatever compiler the user wants, instead of fixind it to clang as shown above.

Thanks

I am aware this is called cmake-ide so probably requires cmake projects to work. If one already has an existing compile_commands.json file, how can that be plugged into this package? Is it even possible to do this? Or perhaps I need to fake a cmake project.

My rtags build directory is not in the system path, so I set cmake-ide-rdm-executable and cmake-ide-rc-executable to the absolute path of the executables. While rdm run as expected, rc is not found:

cmake-ide [Tue Mar 15 15:33:56 2016]: Running rc for rtags
error in process sentinel: rtags-call-rc: Can’t find rc
error in process sentinel: Can’t find rc

Looking at the code in cmake-ide.el, I suppose the problem is that the cmake-ide-rc-executable variable is declared but never used.
Manually setting the rtags-path variable to the path of the directory of rc and rdm executables solves the problem, but isn't there a way to get this automatically?

I might fix this myself. Just leaving this here for information and in hope of additional creative input.

When I found use-package and req-package I started deferring the load of packages to reduce the Emacs startup time. In that process I kind of ran into a wall concerning cmake-ide and its surrounding packages. Running CMake and setting flags for other packages is only triggered automatically on find-file-hook.

When I defer the load of cmake-ide I have to start things myself for existing buffers.
I am not sure about a nice way to correct this yet. The hook handling in req-package looks like a good idea to start from.

Similar problems arise when cmake-ide is loaded before one of its dependencies. All packages loaded after cmake-ide need at least a cmake-ide-maybe-run-cmake to get their flags set.
Splitting up the flag setting into separate functions for each dependency and hooking them to the loading of those packages with with-eval-after-load could solve this.

At the moment I've got the following advice in my init.el but would be greate to add a one line to set achead:include-directories as well in cmake-ide:

(defun set-ac-c-header-path (buffer flags includes sys-includes)
  (when (buffer-live-p buffer)
    (with-current-buffer buffer
      (make-local-variable 'achead:include-directories)
      (setq achead:include-directories (append achead:include-directories (cmake-ide--flags-to-include-paths flags)))
    )))

(advice-add 'cmake-ide-set-compiler-flags :after #'set-ac-c-header-path)

This probably means that something is wrong with the package headers.