MantisBT - CMake
View Issue Details
0005938CMakeCMakepublic2007-10-23 20:532016-06-10 14:30
Philip Lowman 
Miguel Figueroa 
normalminoralways
closedmoved 
 
 
0005938: Eclipse CDT4 Generator projects fail to detect binaries in directories with same name as project
If you have a directory in your binary tree where you build binary targets and that directory is the same name as your project upon completing the build of your code Eclipse will not detect the binaries in that folder (making you have to setup debugging manually).

CMakeLists.txt:
PROJECT(FooBar)
ADD_SUBDIRECTORY(FooBar)

FooBar/CMakeLists.txt:
ADD_EXECUTABLE(foo foo.cc)

No tags attached.
? eclipse_generator.patch2 (775) 2008-12-24 01:56
https://public.kitware.com/Bug/file/1946/eclipse_generator.patch2
Issue History
2007-10-23 20:53Philip LowmanNew Issue
2007-11-16 16:55Miguel FigueroaStatusnew => assigned
2007-11-16 16:55Miguel FigueroaAssigned To => Miguel Figueroa
2008-06-26 10:52Philip LowmanNote Added: 0012531
2008-10-27 18:28Miguel FigueroaNote Added: 0013950
2008-12-24 01:56Miguel FigueroaFile Added: eclipse_generator.patch2
2008-12-24 02:01Miguel FigueroaNote Added: 0014434
2008-12-30 22:17Miguel FigueroaNote Added: 0014456
2009-02-21 12:53Philip LowmanNote Added: 0015284
2009-03-12 03:02Miguel FigueroaNote Added: 0015666
2009-03-12 08:01Philip LowmanNote Added: 0015667
2016-06-10 14:27Kitware RobotNote Added: 0041395
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0012531)
Philip Lowman   
2008-06-26 10:52   
Just discovered that this also affects binaries with the same name as the project as well as directories. I'm assuming it's the same bug. Trivial reproducer (witnessing this on Eclipse Ganymede, CMake 2.6.0):

1. Create
foo/CMakeLists.txt:
PROJECT(foo)
ADD_EXECUTABLE(foo foo.cc)

2. mkdir foo.build completely outside of build tree

3. cmake -G "Eclipse CDT4 - Unix Makefiles" ../foo

4. import into Eclipse

5. build

6. "foo" executable never gets detected as a binary.

7. Change executable target name to "bar" and build, is detected.
(0013950)
Miguel Figueroa   
2008-10-27 18:28   
Philip,

This seems to be a problem with eclipse not the cmake generator.

If after generating the project with CMake you can find a pathentry (look for <pathentry ... kind="out" path=""/>) line that makes these binaries recognized, then send me a note and I'll get the generator to create it automatically.

However, it seems it has conflicts with the linked resources and I can't get executables named the same as these resources or nested in a directory named as the linked resources to be recognized.

Hence, I'll close this one until a solution is found and can be revisited.

Thanks,
--Miguel
(0014434)
Miguel Figueroa   
2008-12-24 02:01   
I have attached a proposed patch. This basically obfuscates the linked resource name with a ".lnk" extension, so that these collisions are made much less probable.

Comments?

--Miguel
(0014456)
Miguel Figueroa   
2008-12-30 22:17   
I have to reverse my proposal since this makes OutOfSource Build Debugging very difficult if not impossible. That is the reason that the LinkedResources still exist even with the -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE option.

That is, even when you use this option to create a simple project in the source directory to use Eclipse to interact with Subversion/CVS you still can't appropriately debug the source files unless the linked directories exist.

Until, some other method for this is proposed... like an automatic mapping so that eclipse knows where to search for Source files (relative to some directory for example) we can't get rid of the linked resources or obfuscate them as I intended.

Comments?

--Miguel
(0015284)
Philip Lowman   
2009-02-21 12:53   
So making project(foo) create a LinkedResource "foo.lnk" breaks out-of-source debugging?
(0015666)
Miguel Figueroa   
2009-03-12 03:02   
Yes, basically each time you step into a new file it can't find it. It allows you to browse for it, but you can imagine how annoying this can become.
(0015667)
Philip Lowman   
2009-03-12 08:01   
Is there a better solution than iterating through all source directory names and all executable targets and comparing with known project names? At best CMake could certainly issue a warning.
(0041395)
Kitware Robot   
2016-06-10 14:27   
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.