add external library and add_subdirectory to project tree

[ksrp1984]

When I add "include_directories" they are added in the eclipse project. But if I use "add_library" or "add_subdirectory" which are not in the root directory of the project, then they are not displayed in the eclipse project. Maybe I'm doing something wrong in my CMakeList? Or is it impossible to add display of external files in the cmake4eclipse project? Is it possible to implement this somehow?

[15knots]

Am Samstag, 18. November 2023, 09:56:53 CET schrieb ksrp1984:

When I add "include_directories" they are added in the eclipse project. But if I use "add_library" or "add_subdirectory" which are not in the root directory of the project, then they are not displayed in the eclipse

Your are talking of cmake commands here, right? The plugin does not parse any cmakelists.txt, so it will not show libraries or dierectories. The includes folder is fed by the indexer which in turn is fed from parsing the compile_commands.json file generated by cmake in the build directory.

project. Maybe I'm doing something wrong in my CMakeList? Or is it impossible to add display of external files in the cmake4eclipse project?

You might want to add a 'linked folder' in the project but you have to enable linked folders for your workbench first.

Is it possible to implement this somehow?

/ Martin

…

-- Cd wrttn wtht vwls s mch trsr.

[inxksp]

I added symbolic links. Now the parser correctly analyzes functions and variables. But it doesn't recognize target_compile_definitions for subdirectories. Even if I add a definition with the "public" option to a subdirectory, this definition is correctly recognized by the parser in the main target's sources, but the parser does not see it in the subdirectory. The definition was added correctly to compile_commands.json. The compiler works correctly, i.e. all makefiles are created correctly. The problem is only with the parser

Perhaps the problem is that compile_commands.json contains the real path to the file and definitions of variables for this file. And the parser sees a link that is located in the project directory. Perhaps he thinks that these are different files? But then why does it correctly recognize the functions.

[15knots]

I added symbolic links. Now the parser correctly analyzes functions and variables. But it doesn't recognize

symbolic links are not 'linked folders'. The latter can be added in the project properties on the Source Folders page.
You have to enable linked folders for your workbench first.

[ksrp1984]

I tried it, nothing changed. The parser does not see compilation definitions in linked folders

[ksrp1984]

symbolic links are not 'linked folders'. The latter can be added in the project properties on the Source Folders page.
You have to enable linked folders for your workbench first.

Is it possible to look at the "cmake compilation DB" log. What data is transferred from it to the indexer. Only include directories are displayed in the project settings (Preprocessor Include Paths Macros etc). This may help me understand what the problem is, it's probably an internal parser error.

System: Windows, compiler: arm-none-eabi-gcc

[inxksp]

I looked at the parser log output. For the main file there is a section "Macro definitions (option -D)"
main.cpp:
Macro definitions (option -D):
DEBUG=1
SHARE_VAR=1
............
Macro definitions (from language + headers in index):
__builtin_offsetof(T,m)=(reinterpret_cast <size_t>(&reinterpret_cast <const volatile char &>(static_cast<T*> (0)->m)))
__builtin_types_compatible_p(x,y)=__builtin_types_compatible_p(sizeof(x),sizeof(y))
............

But for a file in a subdirectory only "Macro definitions (from language + headers in index)". There is no "Macro definitions (option -D)".

In compile_commands.json the -D macros are the same for all files

[ksrp1984]

I was able to solve this problem by adding providers: Compilation Database Parser + CDT GCC Build Output Parser. For CDT The GCC build output parser needs to add "arm-none-eabi" to the "compiler command pattern". This works with the GCC compiler, but a solution could not be found for the IAR compiler (ARMCC).
Cmake compilation DB cannot determine compiler definitions (both arm-none-eabi and armcc).