MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015150CMakeCMakepublic2014-09-11 05:292016-06-10 14:31
ReporterMartin Oberhuber 
Assigned ToAlex Neundorf 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformIntel x86_64OSUbuntu LinuxOS Version12.04.5 LTS
Product VersionCMake 3.0.1 
Target VersionFixed in Version 
Summary0015150: Eclipse generator produces very bad symbol browsing quality for plain C, due to __cplusplus being set unconditionally
DescriptionWhen I import my plain C project generated with the "Eclipse CDT4 - Unix Makefiles" generator into Eclipse, I see very bad symbol quality:

Indexed 'myproject@linux64' (365 sources, 800 headers) in 24.2 sec: 81,605 declarations; 665,941 references; 54 unresolved inclusions; 3,708 syntax errors; 107,398 unresolved names (13%)

Note the 13% unresolved names, which means that the calltree (referenced-by) will fail 13% of the time ! This is way too unreliable.

Investigation showed that the main problem is cmake generating "__cplusplus=1" unconditionally into the Project Properties > C/C++ Include Paths. When deleting the incorrect __cplusplus setting I get almost perfect symbol quality:

Indexed 'myproject@linux64' (365 sources, 800 headers) in 23.2 sec: 98,095 declarations; 785,956 references; 54 unresolved inclusions; 2,230 syntax errors; 4,732 unresolved names (0.53%)

--> Note only 0.53% unresolved names now (in this case due to some Windows headers). Also note that a __cplusplus macro will be added automatically by Eclipse CDT when looking at any *.cpp / *.cxx / *.cc files. So that macro really should not be set hard-coded by the project generator !
Steps To Reproducecmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ECLIPSE_VERSION=4.4 ../myproject
make
# Now import the generated project into Eclipse for C/C++ 4.4
Additional InformationWorkaround:

After importing the generated project, right-click > C/C++ Include Paths and manually delete the __cplusplus macro setting.
TagsNo tags attached.
Relationships
related to 0015925closed Kitware Robot Reproduce preprocessor definitions specified with target_compile_definitions() in Eclipse project file 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-09-11 05:29Martin OberhuberNew Issue
2014-09-11 06:05Sergei NikulovNote Added: 0036782
2014-09-11 06:21Martin OberhuberNote Added: 0036783
2014-09-11 16:09Alex NeundorfAssigned To => Alex Neundorf
2014-09-11 16:09Alex NeundorfStatusnew => assigned
2016-01-18 14:12Richard LangNote Added: 0040254
2016-01-19 10:09Brad KingRelationship addedrelated to 0015925
2016-02-24 16:16Alex NeundorfNote Added: 0040540
2016-06-10 14:29Kitware RobotNote Added: 0042628
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036782)
Sergei Nikulov   
2014-09-11 06:05   
Have you experiment with project directive in your CMakeLists.txt ?
For example explicitly set C language for project.

> project(you_project_name C)
(0036783)
Martin Oberhuber   
2014-09-11 06:21   
No, I haven't experimented with that and it wouldn't be a solution IMO. We have several "mixed source" projects where both C and C++ sources exist. Generating __cplusplus for browsing is simply wrong, IMO.
(0040254)
Richard Lang   
2016-01-18 14:12   
Encountered same problem with CMake 3.4.1 where cmake lists file explicitly stated that project sources were C/ASM rather than C++

...

# Configure project and languages
project(${TARGET} C ASM)
(0040540)
Alex Neundorf   
2016-02-24 16:16   
Ok, I can reproduce one problem.
If C (and ASM) is the only enabled language in the project,
then the CXX stuff doesn't get into the project file.
So far so good.
As soon as CXX has been enabled at least once in one build tree,
the CXX macros go into the project file and are not removed if CXX is disabled
later on again in the same build tree.

This will be fixed in the next version.

I hope this is the problem you are seeing ?
(0042628)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.