(0029887)
Alex Neundorf (developer)
2012-07-03 05:16

And it works neither for OpenGL nor for Glut ?
From the different directories which are found as you posted, I would have expected that it should work for one of the two.

So, works for neither of the two ?

(0029889)
Nicholas Yue (reporter)
2012-07-03 05:58

I can reconfirmed that it works for neither of them, OpenGL nor GLUT.

My observation is that the problem starts when Eclipse was not able to resolve the #include for neither OpenGL nor GLUT.

Take GLUT as an example, we get the following:
        GLUT_INCLUDE_DIR /System/Library/Frameworks/GLUT.framework/Headers

In the source code, for the OS X platform, the include is defined as
        #include <GLUT/glut.h>

However, the file "glut.h" is found in the directory :
        /System/Library/Frameworks/GLUT.framework/Headers
there is no subdirectory called "GLUT".
I believe that GLUT being a framework would trigger gcc on OS X to create a virtual directory existence.
My conjecture is something along the line of
        #include <[Framework-Name]/header.h>

So the Eclipse/CDT on OS X may need to use the above convention to look for headers in the right place. Assuming my observation is correct.

(0029892)
Alex Neundorf (developer)
2012-07-03 07:03

Right.
I actually have no idea how to fix this.
CMake simply adds the include dirs it knows about to the .cproject file.
Now if the header as e.g. GLU/glut.h does not actually exist like this one the file system, I don't know how to convince eclipse.

Can you try to find out whether eclipse has some special support for frameworks ?
I.e. can you do something manually to make it work ?
If you succeed, I'd be very interested in the resulting .cproject file.
Maybe eclipse has some special tags or something for frameworks in its .cproject file.

(0029910)
Nicholas Yue (reporter)
2012-07-04 23:25

There is a mentioned about something new call "Language Setting Provider", it might be useful

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

The above bug is marked as closed recently so I believe it is possible when generating CDT for version 8 and later.

(0030142)
Alex Neundorf (developer)
2012-07-28 05:29

Yes, this looks like it could work.
But I don't have access to a Mac.
Can you try whether setting those options in Eclipse makes it work for you, and if it does, send me the .project and .cproject files ?

(0030146)
Nicholas Yue (reporter)
2012-07-29 03:02

I have tied out the a nightly build version of CDT which incorporated the changes and generate a new project via the Eclipse wizard and it does work resolving the OpenGL framework header and all the associated functions in OpenGL.

I have attached both the .project and .cproject for your reference.

(0030147)
Alex Neundorf (developer)
2012-07-29 04:21

Thanks.
Can you try to generate Eclipse project files for you project with cmake, and then add the line

<storageModule moduleId="org.eclipse.cdt.core.LanguageSettingsProviders"/>

at an appropriate place, i.e. directly after a closed </storageModuke>, into the generated .cproject file, and let me know whether this changes anything for you ?

(0030148)
Nicholas Yue (reporter)
2012-07-29 08:18

I have done as suggested but it didn't work.

I have tried closing and re-opening the project.

I have tried re-indexing.

(0030149)
Alex Neundorf (developer)
2012-07-29 15:08

Hmm. I checked closer, and still didn't see a difference which might be the key to this.

Could you maybe create a hello-world style small program which uses OpenGL with a basic makefile (e.g. created by the normal Makefile-generator of cmake), and then manually set up a makefile-based project in Eclipse, and fiddle around until it can resolve the headers, and then send me the .project and .cproject files ?

(0030210)
Alex Neundorf (developer)
2012-08-10 15:48

Can you give the HandleMacFrameworkIncludeDirs_13465 branch on cmake stage a try ?
http://cmake.org/gitweb?p=stage/cmake.git [^]
Maybe I fixed it, I removed the frameworks component from the include dir, maybe that's what Eclipse expects.

(0030325)
Nicholas Yue (reporter)
2012-08-11 14:43

I have given the HandleMacFrameworkIncludeDirs_13465 branch a tried. It does not resolve the problem.

I have been on the road for the last week and will be for another week. I have not been able to create the .project .cproject, I think that would shed more light.

(0031275)
Alex Neundorf (developer)
2012-10-18 14:02

I didn't get around to fix it for this release...

(0042076)
Kitware Robot (administrator)
2016-06-10 14:28

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
2012-07-01 19:37	Nicholas Yue	New Issue
2012-07-02 05:34	Alex Neundorf	Assigned To	=> Alex Neundorf
2012-07-02 05:34	Alex Neundorf	Status	new => assigned
2012-07-03 05:16	Alex Neundorf	Note Added: 0029887
2012-07-03 05:58	Nicholas Yue	Note Added: 0029889
2012-07-03 07:03	Alex Neundorf	Note Added: 0029892
2012-07-04 23:25	Nicholas Yue	Note Added: 0029910
2012-07-28 05:29	Alex Neundorf	Note Added: 0030142
2012-07-29 03:02	Nicholas Yue	Note Added: 0030146
2012-07-29 03:03	Nicholas Yue	File Added: cdt.tbz
2012-07-29 04:21	Alex Neundorf	Note Added: 0030147
2012-07-29 08:18	Nicholas Yue	Note Added: 0030148
2012-07-29 15:08	Alex Neundorf	Note Added: 0030149
2012-08-10 15:48	Alex Neundorf	Note Added: 0030210
2012-08-11 14:43	Nicholas Yue	Note Added: 0030325
2012-08-13 12:38	Alex Neundorf	Target Version	=> CMake 2.8.10
2012-10-18 14:02	Alex Neundorf	Note Added: 0031275
2012-10-18 14:02	Alex Neundorf	Target Version	CMake 2.8.10 => CMake 2.8.11
2013-05-17 09:33	Robert Maynard	Target Version	CMake 2.8.11 => CMake 2.8.12
2016-06-10 14:28	Kitware Robot	Note Added: 0042076
2016-06-10 14:28	Kitware Robot	Status	assigned => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0029887) Alex Neundorf (developer) 2012-07-03 05:16	And it works neither for OpenGL nor for Glut ? From the different directories which are found as you posted, I would have expected that it should work for one of the two. So, works for neither of the two ?

(0029889) Nicholas Yue (reporter) 2012-07-03 05:58	I can reconfirmed that it works for neither of them, OpenGL nor GLUT. My observation is that the problem starts when Eclipse was not able to resolve the #include for neither OpenGL nor GLUT. Take GLUT as an example, we get the following: GLUT_INCLUDE_DIR /System/Library/Frameworks/GLUT.framework/Headers In the source code, for the OS X platform, the include is defined as #include <GLUT/glut.h> However, the file "glut.h" is found in the directory : /System/Library/Frameworks/GLUT.framework/Headers there is no subdirectory called "GLUT". I believe that GLUT being a framework would trigger gcc on OS X to create a virtual directory existence. My conjecture is something along the line of #include <[Framework-Name]/header.h> So the Eclipse/CDT on OS X may need to use the above convention to look for headers in the right place. Assuming my observation is correct.

(0029892) Alex Neundorf (developer) 2012-07-03 07:03	Right. I actually have no idea how to fix this. CMake simply adds the include dirs it knows about to the .cproject file. Now if the header as e.g. GLU/glut.h does not actually exist like this one the file system, I don't know how to convince eclipse. Can you try to find out whether eclipse has some special support for frameworks ? I.e. can you do something manually to make it work ? If you succeed, I'd be very interested in the resulting .cproject file. Maybe eclipse has some special tags or something for frameworks in its .cproject file.

(0029910) Nicholas Yue (reporter) 2012-07-04 23:25	There is a mentioned about something new call "Language Setting Provider", it might be useful https://bugs.eclipse.org/bugs/show_bug.cgi?id=69529 [^] The above bug is marked as closed recently so I believe it is possible when generating CDT for version 8 and later.

(0030142) Alex Neundorf (developer) 2012-07-28 05:29	Yes, this looks like it could work. But I don't have access to a Mac. Can you try whether setting those options in Eclipse makes it work for you, and if it does, send me the .project and .cproject files ?

(0030146) Nicholas Yue (reporter) 2012-07-29 03:02	I have tied out the a nightly build version of CDT which incorporated the changes and generate a new project via the Eclipse wizard and it does work resolving the OpenGL framework header and all the associated functions in OpenGL. I have attached both the .project and .cproject for your reference.

(0030147) Alex Neundorf (developer) 2012-07-29 04:21	Thanks. Can you try to generate Eclipse project files for you project with cmake, and then add the line <storageModule moduleId="org.eclipse.cdt.core.LanguageSettingsProviders"/> at an appropriate place, i.e. directly after a closed </storageModuke>, into the generated .cproject file, and let me know whether this changes anything for you ?

(0030148) Nicholas Yue (reporter) 2012-07-29 08:18	I have done as suggested but it didn't work. I have tried closing and re-opening the project. I have tried re-indexing.

(0030149) Alex Neundorf (developer) 2012-07-29 15:08	Hmm. I checked closer, and still didn't see a difference which might be the key to this. Could you maybe create a hello-world style small program which uses OpenGL with a basic makefile (e.g. created by the normal Makefile-generator of cmake), and then manually set up a makefile-based project in Eclipse, and fiddle around until it can resolve the headers, and then send me the .project and .cproject files ?

(0030210) Alex Neundorf (developer) 2012-08-10 15:48	Can you give the HandleMacFrameworkIncludeDirs_13465 branch on cmake stage a try ? http://cmake.org/gitweb?p=stage/cmake.git [^] Maybe I fixed it, I removed the frameworks component from the include dir, maybe that's what Eclipse expects.

(0030325) Nicholas Yue (reporter) 2012-08-11 14:43	I have given the HandleMacFrameworkIncludeDirs_13465 branch a tried. It does not resolve the problem. I have been on the road for the last week and will be for another week. I have not been able to create the .project .cproject, I think that would shed more light.

(0031275) Alex Neundorf (developer) 2012-10-18 14:02	I didn't get around to fix it for this release...

(0042076) Kitware Robot (administrator) 2016-06-10 14:28	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