View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005938CMakeCMakepublic2007-10-23 20:532016-06-10 14:30
ReporterPhilip Lowman 
Assigned ToMiguel Figueroa 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005938: Eclipse CDT4 Generator projects fail to detect binaries in directories with same name as project
DescriptionIf 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)

TagsNo tags attached.
Attached Files? file icon eclipse_generator.patch2 [^] (775 bytes) 2008-12-24 01:56

 Relationships

  Notes
(0012531)
Philip Lowman (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
2009-02-21 12:53

So making project(foo) create a LinkedResource "foo.lnk" breaks out-of-source debugging?
(0015666)
Miguel Figueroa (developer)
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 (developer)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2007-10-23 20:53 Philip Lowman New Issue
2007-11-16 16:55 Miguel Figueroa Status new => assigned
2007-11-16 16:55 Miguel Figueroa Assigned To => Miguel Figueroa
2008-06-26 10:52 Philip Lowman Note Added: 0012531
2008-10-27 18:28 Miguel Figueroa Note Added: 0013950
2008-12-24 01:56 Miguel Figueroa File Added: eclipse_generator.patch2
2008-12-24 02:01 Miguel Figueroa Note Added: 0014434
2008-12-30 22:17 Miguel Figueroa Note Added: 0014456
2009-02-21 12:53 Philip Lowman Note Added: 0015284
2009-03-12 03:02 Miguel Figueroa Note Added: 0015666
2009-03-12 08:01 Philip Lowman Note Added: 0015667
2016-06-10 14:27 Kitware Robot Note Added: 0041395
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team