Re: [cmake4eclipse-users] Problem with unresolved inclusion in C++17 project

[15 knots]

Am Di., 22. Sept. 2020 um 03:45 Uhr schrieb Jim Mayer <j...@pentastich.org>:
>
> Hi,
>
> The application I'm working on is written in C++ 17. I'm running on an Ubuntu 20.04.1 system, using Eclipse 2020-09. I have no problem using the standard builder.

Could you explain `standard builder`? Did you create a CMake Project in CDT?

>
> If I take exactly the same files, create a CMakeLists.txt, and create a cmake driven project using cmake4eclipse, then the application builds perfectly, but the indexer reports a number of errors.
>
> When I inspect "build/Debug/compile_commands.json, I see that each file is compiled correctly with -std=gnu++17.
>
> When I look at a parser log, I see the following system include files, which I think is correct:
> /usr/include
> /usr/local/include
...
> I also notice that __cplusplus is defined and has the right value.
>
> __cplusplus=201703L

The above are the compiler built-ins. The
CMAKE_EXPORT_COMPILE_COMMANDS * Parser's detect these and feed them to
the indexer. Looks good.

> However, down at the bottom of the parser log I see the following problems:
>
> Unresolved includes (from headers in index):
> Unresolved inclusion: stdlib.h in file file:/usr/include/c++/9/cstdlib
> Unresolved inclusion: stdlib.h in file file:/usr/include/c++/9/bits/std_abs.h
> Unresolved inclusion: math.h in file file:/usr/include/c++/9/cmath
> Unresolved inclusion: math.h in file file:/usr/include/c++/9/cmath

These are messages printed by the CDT indexer, IIRC. No idea, why it
cannot find stdlib.h etc., these should be in /usr/include.

> Unresolved names:
> A template id provides illegal arguments for the instantiation: map in file /home/jim/eclipse-workspace/takeout-photos-fixer/Album.h:68
...
>
> Most of the template instantiations that the parser complains about look like this:
> std::map<fs::path, Image>& get_images();
> where "fs" is defined as:
> namespace fs = std::filesystem;
>
> The only one that's different looks like this:
> std::set<std::string> extensions;

Sorry, I am not the C++ expert. These messages stem from YOUR code.
Maybe the CDT indexer does not support c++17?

> I'm suspicious that there's some problem with the language version support, because std::filesystem::path was introduced in C++ 17 and I've had that issue with cmake4eclipse before (in fact, that's why I originally developed this project using the CDT C++ Project builder). This problem is different though. Previously, the indexer in cmake projects wasn't resolving includes like "#include <filesystem>"; it is now, but I'm seeing other errors. Why there would be a problem instantiating a set with std::string is beyond me

If `previously` means CDT prior to 2020-09, that is no surprise: CDT
CMake Preview 2020-09 gained the indexer support from cmake4eclipse,
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=559674. Plus the
cmake error parser, as you may have noticed.

> As I said, with the standard CDT C++ builder I don't see any indexing or building problems, so I assume this is a problem with the way the indexer is being configured, not the indexer itself. Also, the program builds within Eclipse using cmake/make without errors. It's just

Cmake4eclipse does not *configure* the indexer, it just feeds the
indexer with information on the include paths and macros. And well,
cmake4eclipse's CMAKE_EXPORT_COMPILE_COMMANDS * Parser's detect more
include paths than the Language Setting Entries Providers that come
with plain CDT. Maybe cmake4eclipse picks up an include path that
plain CDT doesn't?

Martin