• Create Account

Eclipse parser/autocomplete not recognizing opengl functions? Any alternatives if Eclipse can't do it?

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

8 replies to this topic

#1Krankles  Members   -  Reputation: 258

Like
0Likes
Like

Posted 27 March 2013 - 08:25 PM

Basically, no opengl functions are being recognized by Eclipse's parser and are just telling me that it's an error (which is annoying). I'm using GLFW to create my opengl context and using GLEW to handle everything I need to include to use opengl. The program compiles and runs fine, but the auto complete is just not working for me. Also, I want to complete arguments from the functions.

I want to know if anyone actually got Eclipse working with OpenGL and can complete functions WITH arguments. If this is unsolvable, is there any other alternatives to Eclipse that WILL get the job done? Excluding Visual Studio because I'm on Arch Linux. I'm using Vim as my text editor and using Eclim (which basically uses Eclipse to give me autocomplete, error check, etc) so I can still do everything in Vim without having to actually use an IDE, but if there's no other choice, I will switch to an IDE for the sake of function argument completion.

Thanks.

#2dilyan_rusev  Members   -  Reputation: 668

Like
0Likes
Like

Posted 28 March 2013 - 04:38 AM

I haven't worked that much with CDT, but I've done small projects and it worked perfectly for me. How do you include the OGL headers? Does ctrl+click (go to definition) work? I haven't used GLFW in ages, so I don't really remember if it did some trick like FreeType or SDL. Eclipse's parser should work if it can find the files. There are settings for configuring which directories it should use, but I don't have Eclipse at work, so I'll be able to help more when I go back home.

Anyway, does the regular <GL/gl.h> work? And aren't you running Eclipse itself? I know there is a plugin that emulates VIM in Eclipse, but I'm not familiar with your setup. The only problems I had with CDT were C++11 features that were not yet supported by the parser, but that may have been fixed already.

EDIT:

Yes, there are alternatives. I personally don't like KDevelop, but it does work pretty well if you can actually configure it to work. I've heard people praise QtCreator, but I haven't used it that much. It seemed quite cable of non-Qt code, and it is quite simple. I'd avoid Code::Blocks, since it is quite basic, but if everything else fails, you can give it a go.

Edited by dilyan_rusev, 28 March 2013 - 04:42 AM.

#3Krankles  Members   -  Reputation: 258

Like
0Likes
Like

Posted 28 March 2013 - 01:30 PM

I haven't worked that much with CDT, but I've done small projects and it worked perfectly for me. How do you include the OGL headers? Does ctrl+click (go to definition) work? I haven't used GLFW in ages, so I don't really remember if it did some trick like FreeType or SDL. Eclipse's parser should work if it can find the files. There are settings for configuring which directories it should use, but I don't have Eclipse at work, so I'll be able to help more when I go back home.

Anyway, does the regular <GL/gl.h> work? And aren't you running Eclipse itself? I know there is a plugin that emulates VIM in Eclipse, but I'm not familiar with your setup. The only problems I had with CDT were C++11 features that were not yet supported by the parser, but that may have been fixed already.

EDIT:

Yes, there are alternatives. I personally don't like KDevelop, but it does work pretty well if you can actually configure it to work. I've heard people praise QtCreator, but I haven't used it that much. It seemed quite cable of non-Qt code, and it is quite simple. I'd avoid Code::Blocks, since it is quite basic, but if everything else fails, you can give it a go.

I included the OGL headers exactly in this order.

#include <GL/glew.h>
#include <GL/glfw.h>
#include <glm/glm.hpp>
#include <SOIL/SOIL.h>
#include <iostream>
#include <ctime>
#include <cmath>


CTRL + Click (Go to Definiton) doesn't work. GLFW works fine (including Go to Definition), but GLEW doesn't work sadly, which is why glBindBuffer, glGenBuffers, etc doesn't work.

And yeah, I tried running Eclipse by itself and it still doesn't work. When I'm testing, I'm always using Eclipse just to make sure it's not Eclim. I'm fine with using an IDE but using VIM is so much more preferable.

Regular <GL/gl.h> doesn't work for some reason either. I'm including it with this, right before everything:

#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>


I even tried without defining GL_GLEXT_PROTOTYPES and it still doesn't work. What's weird is that using the above code with Vim and clang_complete, it shows the function and argument completion, but with eclipse, it doesn't even resolve it.

I even tried adding /usr/include/GL to my include paths in Eclipse, but it still doesn't work.

EDIT: When I include GLEW and stuff, and I use CTRL + CLICK (Go to Definiiton) on functions like glewInit() and glewExperimental, it works. But glBindBuffers and other functions don't work.

EDIT2: Also, I installed eclipse and eclipse-cdt from pacman (Arch Linux's repository manager)

EDIT3: Could someone try Eclipse and try using GLEW? I want to know if it's not my side of the problem and if it does work, does it have argument completion? Thanks. (If anyone knows how to fix my problem, I'd greatly appreciate it).

Edited by Krankles, 28 March 2013 - 04:00 PM.

#4dilyan_rusev  Members   -  Reputation: 668

Like
0Likes
Like

Posted 28 March 2013 - 04:53 PM

Hmm, OK, I've conducted some research on the issue, and as I suspected, somebody (GLEW) actually uses macros This is more than what CDT obviously can handle

Since I'm no longer a hard-core linux user, I've installed the "classic" Eclipse from the web site on Ubuntu, then added the CDT via p2. This is my "lame" code I'm testing with:

#include <GL/glew.h>
#include <GL/glfw.h>
#include <iostream>

int main(int argc, char** argv) {
if (argc == 2) {
glBindBuffer(GL_ARRAY_BUFFER, -1);
}
std::cout<<"compiles"<<std::endl;
return 0;
}


First, it does compile. OGL 1.x functionality can be found (e.g. glBegin(), glVertex2f()...), because it is quite easily defined in glew.h:.

GLAPI void GLAPIENTRY glBegin (GLenum mode);


Now, if we get to the definition of glBindBuffer, which is:

#define glBindBuffer GLEW_GET_FUN(__glewBindBuffer)


~ grep "#define GLEW_GET_FUN" /usr/include/GL/glew.h
#define GLEW_GET_FUN(x) x
~ grep "__glewBindBuffer;" /usr/include/GL/glew.h
GLEW_FUN_EXPORT PFNGLBINDBUFFERPROC __glewBindBuffer;
~ grep "#define GLEW_FUN_EXPORT" /usr/include/GL/glew.h
#define GLEW_FUN_EXPORT
#define GLEW_FUN_EXPORT GLEWAPI
(we can safely assume it's nothing on Linux)
~ grep "PFNGLBINDBUFFERPROC" /usr/include/GL/glew.h
typedef void (GLAPIENTRY * PFNGLBINDBUFFERPROC) (GLenum target, GLuint buffer);
GLEW_FUN_EXPORT PFNGLBINDBUFFERPROC __glewBindBuffer;
(we are searching for the first one.. which is the function signature)


hmm. A lot of #define and typedef magic Most C++ parsers would die at the very first define Let's see if we can cheat, though

Now that we know that the problem is (MACROS), we ca implement a hack. First, go off and download your personal copy of glext.h from http://www.opengl.org/registry/api/glext.h. Place it in your project's root directory. Now, let's change the source of our little hack to:

#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include "glext.h"
#include <iostream>

int main(int argc, char** argv) {
if (argc == 2) {
glBindBuffer(GL_ARRAY_BUFFER, -1);
}

std::cout<<"compiles"<<std::endl;
return 0;
}

Now, that DOES compile, however I can't verify that it will run (as I'm not really an OGL person, and it's quite too late to write an example). However, if it does run with GLEW, it should run that way, too, provided you still link to the same libraries. I know, it is an ugly hack, but it does work. I haven't spent the time to test whether it works on other IDEs (QtCreator and KDevelop). Hope that helps.

#5Krankles  Members   -  Reputation: 258

Like
0Likes
Like

Posted 28 March 2013 - 05:10 PM

I already did that before (if you read my post) and it didn't work. I also tried QtCreator and for some odd reason, it still doesn't work either. Also, I stated before, that my code runs fine (since I'm not really using an IDE to compile, I'm using cmake/make to do it for me) except the fact that the auto complete isn't working for me at all.

EDIT: So actually, QtCreator does work, however, it doesn't give me argument completion, it only gives me the function. I'm using GLEW by the way, and defining prototypes won't work on windows and not for anything outside of GL 1.1, and it may or may not work on MacOSX. So defining GL_GLEXT_PROTOTYPES is not an option since I want it to be cross platform compatible. If anyone knows how I can fix this problem of QtCreator not parsing the function pointer to the point that it can get the arguments, please tell me.

Edited by Krankles, 28 March 2013 - 08:58 PM.

#6dilyan_rusev  Members   -  Reputation: 668

Like
0Likes
Like

Posted 29 March 2013 - 04:57 AM

The difference is that you use the system-provided glext. When you use the one provided by the official web site, at least on my machine, Eclpse works perfectly. Plus, cross-platform is not a problem - this hack would be enabled only in debug builds. Plus, if it is cross-platform, VS most definitely handles this, and I would find it surprising if XCode didn't work with glew (meaning that if a platform-specific issue comes up, you can effortlessly work in native environment, and use VIM in linux for the major dev effort).

#7Krankles  Members   -  Reputation: 258

Like
0Likes
Like

Posted 29 March 2013 - 06:44 AM

The difference is that you use the system-provided glext. When you use the one provided by the official web site, at least on my machine, Eclpse works perfectly. Plus, cross-platform is not a problem - this hack would be enabled only in debug builds. Plus, if it is cross-platform, VS most definitely handles this, and I would find it surprising if XCode didn't work with glew (meaning that if a platform-specific issue comes up, you can effortlessly work in native environment, and use VIM in linux for the major dev effort).

No, I'm saying that defining GL_GLEXT_PROTOTYPES will cause me problems later on, which is why I need a good IDE that I can use that is able to complete arguments via function pointers. Visual Studio definitely works perfectly with GLEW and gives you argument completion, just that any other IDE outside of Windows is incapable of doing so.

I would prefer it if the IDE has support for VIM keybindings too, but if not, I'll still use it over VIM if it has actual argument completion for OpenGL functions.

Edited by Krankles, 29 March 2013 - 06:45 AM.

#8dilyan_rusev  Members   -  Reputation: 668

Like
0Likes
Like

Posted 29 March 2013 - 07:35 AM

Well, I will try to research this when I'm at home. No Linux or Eclipse at work

BTW, function pointers aren't the problem, the parser chokes at two or three-level abstraction introduced by macros. That means it stops resolving after it finds the first macro, i.e it treats glGetBuffer as GLEW_GET_FUN(__glewBindBuffer), which it doesn't parse recursively in order to get to typedef void (GLAPIENTRY * PFNGLBINDBUFFERPROC) (GLenum target, GLuint buffer). Also, I'm not sure if the parser would be able to handle the typedef, either

This is a complex problem (building AST is one of the shittiest things I've had to do), and many programmers lack the motivation and skill to do this. Plus, most of the time you want to use the information provided by the parser, the code is in broken state (open brackets, missing semicolon, etc), which even further complicates the problem. This is why I trust in commercial IDEs - because solving these problems requires a shitload of effort and dedication, and money is one of the best incentives for developers to do dirty and shitty work when they can do something more interesting

#9Krankles  Members   -  Reputation: 258

Like
0Likes
Like

Posted 29 March 2013 - 07:40 AM

Well, I will try to research this when I'm at home. No Linux or Eclipse at work

BTW, function pointers aren't the problem, the parser chokes at two or three-level abstraction introduced by macros. That means it stops resolving after it finds the first macro, i.e it treats glGetBuffer as GLEW_GET_FUN(__glewBindBuffer), which it doesn't parse recursively in order to get to typedef void (GLAPIENTRY * PFNGLBINDBUFFERPROC) (GLenum target, GLuint buffer). Also, I'm not sure if the parser would be able to handle the typedef, either

This is a complex problem (building AST is one of the shittiest things I've had to do), and many programmers lack the motivation and skill to do this. Plus, most of the time you want to use the information provided by the parser, the code is in broken state (open brackets, missing semicolon, etc), which even further complicates the problem. This is why I trust in commercial IDEs - because solving these problems requires a shitload of effort and dedication, and money is one of the best incentives for developers to do dirty and shitty work when they can do something more interesting

But is there any equivalent IDE's to Visual Studio that CAN recursively parse it like Visual Studio can? Or is there any other extension loader that's like GLEW that makes it easier for the parser to parse through it?

Thanks.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS