MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015382CMakeCMakepublic2015-01-29 13:152016-06-10 14:31
Reportervoid.pointer 
Assigned ToAlex Neundorf 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformEclipse CDT4 - NinjaOSWindowsOS Version7 x64
Product VersionCMake 3.1.1 
Target VersionFixed in Version 
Summary0015382: Unable to specify resource filters in Eclipse project
DescriptionI generate my project using Eclipse CDT4 - Ninja. I have a subdirectory called "Third Party" under my source directory that contains boost, QT, and a number of other very large libraries. I notice that the C++ indexer in Eclipse processes files in these directories and frequently locks up my machine or crashes. Indexing takes up to 30 minutes if it decides to complete.

There should be a way I can specify resource filters in CMake scripts. If I can do this, I can tell Eclipse to ignore the directories I don't want it to scan or care about. I'd also be able to tell it to ignore .SO files, .A files, and other non-source file types that way when I use the Open Resource window in Eclipse, I do not see object files and binaries in the search results.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-01-29 13:15void.pointerNew Issue
2015-01-29 13:48Alex NeundorfAssigned To => Alex Neundorf
2015-01-29 13:48Alex NeundorfStatusnew => assigned
2015-09-10 09:55Gregory KramidaNote Added: 0039395
2015-09-10 10:00Gregory KramidaNote Edited: 0039395bug_revision_view_page.php?bugnote_id=39395#r1887
2016-02-24 17:09Alex NeundorfNote Added: 0040542
2016-02-24 18:27Gregory KramidaNote Added: 0040544
2016-02-24 18:28Gregory KramidaNote Edited: 0040544bug_revision_view_page.php?bugnote_id=40544#r2037
2016-06-10 14:29Kitware RobotNote Added: 0042706
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0039395)
Gregory Kramida   
2015-09-10 09:55   
(edited on: 2015-09-10 10:00)
The proposed fix is also a potential fix for the problem I am experiencing with eclipse indexer getting confused due to duplicate paths in CMake-generated eclipse CDT (Makefile) project. (Mentioned here: http://www.cmake.org/Bug/view.php?id=15725#c39382 [^])

A large project with multiple subprojects generates a source tree, duplicate links to source files under the [Targets], and triplicate links to the same source files under the [Subprojects] virtual folder. CDT's "open declaration" then keeps re-opening the same files multiple times, which causes editing/saving conflicts, GUI cluttering, and general confusion (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=471990 [^] [^]).

Another potential solution is to switch to generating eclipse Workspaces instead of projects, with CMake subproject == project, and a single source tree for each project (see http://www.cmake.org/Bug/view.php?id=15298 [^]).
(0040542)
Alex Neundorf   
2016-02-24 17:09   
The Eclipse documentation says that resource filters are not applied to linked resources, since they are created explicitely by the user.
So basicaly, you'd be better off without the subproject- and target-links ?
(0040544)
Gregory Kramida   
2016-02-24 18:27   
(edited on: 2016-02-24 18:28)
@Alex Neundorf, actually, it seems like the CDT devs have already solved that issue. My problem really stemmed from their indexer ambiguously picking between files under [Subprojects] and their non-virtual-folder equivalents. Based on my feedback they made the indexer open up the non-virtual-folder things in all such cases.
Also, my assertion about the bug duplicate was wrong. Virtual folders are not linked resources, I just got confused at some point.
(0042706)
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.