Conflicts with glx

h3r3tic · Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland

I've run into problems with derelict.opengl.gl publicly importing derelict.opengl.glx. It causes lots of conflicts in my projects, having declared names like Window or Font. My suggestion is that gl should **privately** import glx (and for the sake of consistency, wgl) since it's almost never needed at all. The code that needs these should IMO use a version() and import glx or wgl privately as well. I've modified my own copy of Derelict this way and I can see no downsides.

Greetz,
Tom

JJR · Joined: 22 Feb 2004 Posts: 1104

Sounds like a good idea. Mike, what do you think? I tend to agree that the library user should explicitly import glx if they need it anyway..

-JJR

aldacron · Posted: Thu May 19, 2005 5:47 am Post subject:

Works for me. I guess it will have to be the same for wgl. But, what I will do is move the stuff out into separate modules and import them privately from there. That way, people who want to use those extra declarations (when going through the Win32 API for example) will be able to without looking for a separate library. Perhaps I should patch that stuff into std.c.windows.windows and send it to Walter.

aldacron · Posted: Tue May 24, 2005 10:57 am Post subject:

Okay, I've got wgl sorted. That's in the trunk now. I'm not too confident on the glx stuff, though. If anyone else can get to it before I can, I'd appreciate it.

JJR · Joined: 22 Feb 2004 Posts: 1104

I'll check it out as soon as I can....

h3r3tic · Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland

IMO these definitions in glx.d can cause lots of problems (they do in my case):

typedef void Display;
typedef XID Pixmap;
typedef XID Font;
typedef XID Window;

And they still do with the new version from the trunk.
In my experience, gl.d should not import glx nor wgl at all. If someone needs these platform specific tools, they should import glx or wgl explicitly. And if this is too much hassle for the user, maybe there should be derelict.opengl.foobar (or some more reasonable name Wink

) that imports all of these (assuming there will be more, like glmac, etc), enclosed in a few 'version' statements.

JJR · Joined: 22 Feb 2004 Posts: 1104

I haven't made any changes yet to the glx import. I'll have a look promptly. I agree that importing glx should be a user decision.

-JJR

JJR · Joined: 22 Feb 2004 Posts: 1104

Oops... sorry, looks like I no longer have commit access to this project. I can't help here.

It looks like Mike hasn't changed the public imports in gl.d still. Linux and Win32 versions still import glx and wgl.

Maybe he can update both.

-JJR

h3r3tic · Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland

Damn, sorry. I thought you meant "I'll check if everything's fine with it" by saying "I'll check it out as soon as I can...." Rolling Eyes

No hurry then, When I remove the glx and wgl imports from gl.d, everything's fine Smile

JJR · Joined: 22 Feb 2004 Posts: 1104

h3r3tic · Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland

JJR · Joined: 22 Feb 2004 Posts: 1104

Yep... looks that way... you lucky guy you!

That's almost like time travel, eh?

h3r3tic · Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland

JJR · Joined: 22 Feb 2004 Posts: 1104

That was a killer! Thanks for the link. I didn't see it on the newsgroup.

-JJR

aldacron · Posted: Wed May 25, 2005 7:13 pm Post subject:

The fix is now in the trunk: gl.d no longer imports wgl or glx. And I'll ask Brad to get you back on the commit list, John. I thought you still could.