(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

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.

Relationships