Am Donnerstag, 28. Januar 2016, 11:05:13 schrieb Emil Huseynli:
> Hello,
>
> i'm using the plugin for a while and i would like to say i'm very pleased
> with it. The plugin does his job very well.
I'm pleased to hear that.
> Recently I started working on a Qt based cmake project. Cmake has a good
> support for Qt and, as I expected, I was able to build my project using the
> plugin, but... I have to manually enter Qt include paths in project
> preferences to make Eclipse indexer happy.
The plugin has a parser for the build output. That parsers tries to detect
invocations of the C/C++ compiler, extract include directories and
preprocessor defines and feed them to the indexer.
It can be enabled in
Project Settings|C/C++ General|Preprocessor Include Paths...
on the Providers tab: CMake Build Output Parser.
Parsing the build output to feed the indexer works well on linux with make and
gcc. It cannot work if
- the build tool does not print the compiler commands (as with ninja),
- the cmake generator decides to pass compiler commands in a separate file (as
with make under windows),
- the compiler arguments are not POSIX compatible ('-D' for marocs, '-I' for
include dirs, command name 'cc') as with the microsoft compiler.
>
> Am i missing something here? Is it possible somehow enable auto discovery
> of third-party libraries header files? Maybe plugin is capable to parse
> cmake output regarding that?
Sorry, that won't help. The output of cmake, when generating the build
scripts, does not show any include paths and macros.
For an indexer of CDT (or any IDE) with preprocessor symbols and include
paths, it must know
1) the compiler built-ins
- easy to get on *nix, some OS standards dictate these
-- easier on linux with gcc; gcc is in $PATH and has an option to spit out the
builtins willingly
- OSX: I don't know
- hard on windows; no OS standards enforcing the location on headers, no
standard to get the built-in #defines.
2) the include paths of each 3rd-party library
- cmake does a fairly good job to find these
. cmake does not provide a way to tell IDEs of its findings.
-- there have been suggestion on the cmake-dev mailing list to improve the
situation: EXPORT_COMPILE_COMMANDS and the cmake server mode. My plugin could
be enhanced to parse the file produced with 'cmake -D EXPORT_COMPILE_COMMANDS
...', but EXPORT_COMPILE_COMMANDS is there since cmake 2.8.11. On RHEL7 you're
lost, it still comes with v 2.5.8!
But be assured, on the CTD-dev mailing list, the CDT lead voted for 'cmake
support in CDT 9, and it has to be good'.
>
> Thanks in advance.
Sorry, can*t help much here.
What OS/Compiler/cmake version do you use?
Martin
--
Cd wrttn wtht vwls s mch trsr.