[vtk-developers] extension wrangler

[Moreland, Kenneth]

That's an interesting idea, but I don't think I want to implement it.  I can think of several potential problems.
 
1. It forces you to use a shared object / dynamic library for OpenGL.  That might not always be desirable or possible.
2. It complicates portability.  A lot.  We basically have to ensure that we duplicate the method for finding and linking to the OpenGL library.  I have a feeling we would get a lot of users complaining about VTK not finding OpenGL.
3. It "ickifies" any OpenGL code.  Every single OpenGL call would need to be changed to use a loaded function.  Not a super hard problem, but if we miss anything or any developer in the future forgets, everything is going to break in weird ways.  Furthermore, all code using VTK would have to be changed to conform similarly.  That may not even be possible for some applications.
 
-Ken

________________________________

From: David C. Thompson [mailto:dcthomp at sandia.gov]
Sent: Thu 11/17/2005 11:30 AM
To: Moreland, Kenneth
Cc: Jeff Lee; vtk-developers
Subject: RE: [vtk-developers] extension wrangler



> The problem is, it is hard to accurately pick exactly which library
> file a linker is going to link against.  We were running into problems
> where we identified a shared OpenGL library that probably should have
> been used, but the linker was using a different library.  And if the
> binaries are moved to a different machine, the whole thing can break
> down.
> 
> If there was a way to query at runtime what shared objects were
> loaded, identify which one was OpenGL, and then call dlopen on that,
> that would probably work.  However, I don't know of any way to do that
> query.
What if, instead, you don't link to OpenGL at all at compile time? There
would be a class full of static function pointers that rendering classes
could use. At run time you could dlopen OpenGL and populate the function
pointers with valid addresses. That might alleviate some gl.h header
file inconsistencies as well.

        David




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20051118/5d4bcb3a/attachment.html>