Unresolved Symbol reference for CMake Project (with Hello World) Template

[poldi171254]

Hi,
I'm using
++++++++++++++
Eclipse IDE for C/C++ Developers (includes Incubating components)
Version: 2023-09 (4.29.0)
Build id: 20230907-1323
OS: Linux, v.6.2.0-33-generic, x86_64 / gtk 3.24.33
Java vendor: Eclipse Adoptium
Java runtime version: 17.0.8.1+1
Java version: 17.0.8.1
++++++++++++++

and have the problem that the default "Hello World" code reports the "Symbol 'cout' could not be resolved".

I can build the project without errors
++++++++++++++++++++++++++
Configuring in: /home/llist/sec1/eclipseWorkspace/Test1/build/default
cmake -G Unix Makefiles -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /home/llist/sec1/eclipseWorkspace/Test1
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/llist/sec1/eclipseWorkspace/Test1/build/default
Building in: /home/llist/sec1/eclipseWorkspace/Test1/build/default
cmake --build . --target all
[ 50%] Building CXX object CMakeFiles/Test1.dir/Test1.cpp.o
[100%] Linking CXX executable Test1
[100%] Built target Test1
Build complete (0 errors, 0 warnings): /home/llist/sec1/eclipseWorkspace/Test1/build/default
++++++++++++++++++++++++++

and when I run it I get
+++++++++++++++++++++++
Hello World
Version 0.1
+++++++++++++++++++++++

but the editor still show unresolved symbol references.

Most suggested solution suggest to modify/add the include path for the Project, but there is no option that I can find.

Thanks,
Leo

[gvl2023]

For me the workaround was to configure the indexer to index files open in editor. Strangely, I then disabled this option but everything continued to work, so perhaps you just need to enable it initially once. One of the many CDT indexer quirks it seems. Just an FYI you can reindex your project (Index/Rebuild) which is supposed to help with this type of issues except it didn't do it for me.

With cmake in Eclipse all include paths are supposed to be discovered automatically, I suspect that is the reason the option to configure include paths is missing from cmake projects.

[sakunix]

same problem =(

[ghentschke]

Please give the new language server based editor a try. It can be used for cmake projects since the language server, like clangd, resolves the includes based on a CompileCommannds.json file in the project root (cmake can generate it during the build). With the new editor you can disable the cdt indexer, because the clangd language server does the indexing. I think the CompileCommannds.json will be generated by default in cdt cmake project.

[gvl2023]

I tried it, and I think it’s the right direction to go as it’s difficult to keep up with the language evolution given the CDT’s team limited resources. What turned me off, apart from beta quality, was the fact the editor looked and felt different than Java an C++ Eclipse editors I’m used to so I’m back to the CDT classic despite all the indexer quirks. I would have preferred the editor to stay the same but the indexer be based on clangd instead, but I’m sure there are technical reasons why this is difficult to realize.

[ghentschke]

Thanks for the feedback. You're right, look and feel is different. It's more similar to other lsp based editors like vscode. We have not reached feature parity with the old editor (yet). Main reason is, that there are features in the old cdt editor which aren't backed by the clangd server e.g. the includes in the outline view. The biggest benefit, the new editor comes along with, is the support of modern cpp standards and a non blocking UI because of the stumbling indexer (when it's disabled of course).

[gvl2023]

Don’t get me wrong, this is great, I’ll happily revisit it as the solution matures. As for the indexer performance, apart from the actual indexing speed, I never had big issues with it. I’m currently working with a fairly large code base, it takes just under an hour to index it on modern hardware and the pdom file is about 2Gb, once the index is built I don’t find the indexer gets in the way, the contex assist and navigation is pretty snappy, definitely on par with Visual Studio. About the only hiccup I experience is after typing :: when it searches in the global namespace (and fails). I would be happy to see the indexer getting some attention like make it take advantage of multiple cores during indexing and better C++ 20 support, but I’m not holding my breath.