MantisBT - CMake
View Issue Details
0013189CMakeCMakepublic2012-05-04 06:042012-10-23 16:43
Eric Beuque 
Alex Neundorf 
normalminoralways
closedfixed 
Eclipse CDTLinux3.2.0
CMake 2.8.7 
CMake 2.8.11CMake 2.8.11 
0013189: [Eclipse CDT] The [Targets] virtual directory contains all sources files which make Eclipse lost
I ran cmake on my project using the following command:
$> cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ .

This create a [Targets] directory that contains all sources files already presents in the eclipse project.
I guess this is the expected output regarding 0012223.

The project compilation work fine, but the problem is that Eclipse see each file twice. This has effect that navigation has not the expected behavior.

For example, i open a file in my original source dir (main.cpp). I CTRL+Click on a token (MyClass::setText function) and it open the virtual file in the related [Targets] directory. I expect it open the original file in my source dir.
- Create a project for Eclipse CDT and run cmake on it.
- CTRL+Click on any token
- It open a file in the [Targets] directory
I see two solutions:
- I think the best is to keep in [Targets] only file that are not present in the original sources dir
- Tell Eclipse indexer to not parse the file present in the [Targets] dir, that are not already present in the original sources dir.
No tags attached.
? out.ogv (1,667,155) 2012-08-23 09:38
https://public.kitware.com/Bug/file/4434/out.ogv
Issue History
2012-05-04 06:04Eric BeuqueNew Issue
2012-05-04 13:52Alex NeundorfAssigned To => Alex Neundorf
2012-05-04 13:52Alex NeundorfStatusnew => assigned
2012-08-09 10:45Eric BeuqueNote Added: 0030196
2012-08-09 16:19Alex NeundorfNote Added: 0030201
2012-08-09 16:35Eric BeuqueNote Added: 0030202
2012-08-13 12:39Alex NeundorfTarget Version => CMake 2.8.10
2012-08-22 16:56Alex NeundorfNote Added: 0030743
2012-08-23 05:17Eric BeuqueNote Added: 0030747
2012-08-23 05:18Eric BeuqueNote Edited: 0030747bug_revision_view_page.php?bugnote_id=30747#r786
2012-08-23 05:18Eric BeuqueNote Edited: 0030747bug_revision_view_page.php?bugnote_id=30747#r787
2012-08-23 09:01Eric BeuqueNote Added: 0030748
2012-08-23 09:38Eric BeuqueFile Added: out.ogv
2012-08-23 09:45Eric BeuqueNote Added: 0030749
2012-08-23 16:23Alex NeundorfNote Added: 0030750
2012-08-23 16:46Eric BeuqueNote Added: 0030751
2012-08-24 11:19Alex NeundorfNote Added: 0030756
2012-10-04 13:17Chris StankevitzNote Added: 0031178
2012-10-16 20:09Chris StankevitzNote Added: 0031251
2012-10-17 17:47Alex NeundorfNote Added: 0031255
2012-10-17 17:47Alex NeundorfStatusassigned => closed
2012-10-17 17:47Alex NeundorfResolutionopen => fixed
2012-10-18 13:33David ColeFixed in Version => CMake 2.8.10
2012-10-23 16:43David ColeNote Added: 0031297
2012-10-23 16:43David ColeFixed in VersionCMake 2.8.10 => CMake 2.8.11
2012-10-23 16:43David ColeTarget VersionCMake 2.8.10 => CMake 2.8.11

Notes
(0030196)
Eric Beuque   
2012-08-09 10:45   
Few months I'm developing with this bug and i saw many boring things:
- Search in files always return 2 result. So search time is twice longer and this can lack performance if your computer is not powerfull (like a in VM). And i you have lot's of result this become unreadable.

- You always have two files opened, because you open the original file and when you use shorcut, eclipse send you to the [Target] dir file. The problem is that if you don't care you edit the file in two different editor, and sometimes you loose data when eclipse sync to two editor.

If you can't easily filter files that should be present or not in the [target] directory, an option to disable the [target] generation could be really welcome.
(0030201)
Alex Neundorf   
2012-08-09 16:19   
This makes it more clear to me.
Do you know whether there is a way to exclude the files in the [Targets] folder in some way from actions like searching ?
(0030202)
Eric Beuque   
2012-08-09 16:35   
Sorry I found nothing to do this, I don't think it is possible, but i'm not an eclipse expert!

I really think the correct way is two remove entry from the target directory that are part of the source directory, because for example you want to keep other files available for searching.

In fact the Eclipse documentation said:
"Linked resources are files and folders that are stored in locations in the file system outside of the project's location. These special resources can be used to add files and folders to your project that for some reason must be stored in a certain place outside of your project."

http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fconcepts-13.htm [^]

By the way an option to disable [targets] generation, could be useful when you don't have any files outside your project location. But it's a temporary fix I think.
(0030743)
Alex Neundorf   
2012-08-22 16:56   
If you right-click on e.g. the [Targets] folder and edit its properties, there is a checkbox
Attributes:
[ ] Derived

If you enable this, and don't enable "Consider derived resources" e.g. in the search dialog, this folder should not be searched anymore.
Does that help ?
(0030747)
Eric Beuque   
2012-08-23 05:17   
(edited on: 2012-08-23 05:18)
It helps!

Files are correctly ignored from file search. But it will ignore also files that are not included in the source directory.

If it is possible, you should also add this properties on generated CMakeFiles directory, which are typically "Derived resource".

Nevertheless, the indexer still parse the file in the [Targets] directory. So i tried so disable "index source files not included in the build". I hope it will tell the parser to not parse these files.

I need to test this configuration for few hours/days, to see if everything is OK or not.

(0030748)
Eric Beuque   
2012-08-23 09:01   
Unfortunately, it doesn't work. The indexer still use the files in the [targets] directory, so when i ctrl+click on a token, it open sometimes the files in the [targets] instead of the file in the source directory.
(0030749)
Eric Beuque   
2012-08-23 09:45   
I sent you a video in attachment to show you what happen exactly with eclipse. Note that Eclispe give a warning when you try to edit a derived file.

I hope it's clear.

I found other problems with breakpoints, sometime you put a breakpoint in the source directory's files, but then you run the debbugger, it open the [targets]'s files, and you don't see your breakpoint.

Tell me if you need more explanation with the problem.
(0030750)
Alex Neundorf   
2012-08-23 16:23   
Unfortunately, it seems CMake can't set this "Derived" property, since Eclipse does not store it in the .project file, but somewhere else.
So, this is anyway more a workaorund.
But I'm glad it helps at least a bit.
(0030751)
Eric Beuque   
2012-08-23 16:46   
Hum... It sucks!

So what will be your choice around this?

Temporarily, is there a script file where I can easily remove the [targets] generation without recompiling cmake?

Sorry, if i'm a little harassing, it just that the indexer's problem is really boring.
(0030756)
Alex Neundorf   
2012-08-24 11:19   
Probably a cmake option...
(0031178)
Chris Stankevitz   
2012-10-04 13:17   
I filed a CDT bug for this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=390964 [^]

In the meantime, please let me know if you have come up with any workarounds.
(0031251)
Chris Stankevitz   
2012-10-16 20:09   
Please... if anyone can suggest a workaround please share. I'm desperate. Or if anyone can refer me to a way to fix this myself. I'm a c++ programmer with no eclipse/plugin/java experience but I'm willing to try as this is so frustrating for me. Thank you!
(0031255)
Alex Neundorf   
2012-10-17 17:47   
I added a switch CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES, which defaults to TRUE, which you can disable e.g. via make edit_cache.
If disabled, the links are not generated.
I hope this will still be accepted for 2.8.10.
It is in the next branch now.
(0031297)
David Cole   
2012-10-23 16:43   
Sorry... this one won't be in 2.8.10, but we will put it in 'master' right afterwards, and it will be in 2.8.11.

In the meantime, you can build from 'next' or download our nightly builds and get the fix before CMake 2.8.11 is available.