On Sat, 11 Mar 2000, Matthew D. Langston wrote:
> The macro MDL_HAVE_OPENGL is what you want. It is in the Autoconf Macro
> Archive at http://peti.cys.de/autoconf-archive/ in the file
> mdl_have_opengl.m4. It should do everything you want. If it doesn't,
> please let me know (or better yet, send me a patch) as I am the original
> author if it.
Cool, this looks very handy. I wish I'd known about it sooner!
> We were originally going to include this macro in the Autoconf package last
> summer, but later decided that the Autoconf Macro Archive would be a better
> place for it, as it is so specialized.
However, the availability of this macro really doesn't solve the problem
I've presented... at least AFAICT.
Suppose I've got a library and I want to install an autoconf macro on the
user's system so that if the user is developing a library dependent on
mine, s/he can use this macro to check for the presence of my library. My
library depends on OpenGL, so the macro I've installed needs to check for
OpenGL.
I can't just call MDL_HAVE_OPENGL to do this check, because I can't assume
it is installed on the system. I need to install MDL_HAVE_OPENGL as well
if I'm going to call it. But if I install it, I risk collision with
someone else who's decided to do the same. So I better rename it.
Now I'm installing and calling MY_MDL_HAVE_OPENGL. This works... until
someone else decides to do the same thing. Now I've got two identical
macros on the system under different names, MY_MDL_HAVE_OPENGL and
THEIR_MDL_HAVE_OPENGL. Now suppose this user creates a library that
depends both on "my" library and "their" library. The user's configure
script calls both HAVE_MY_LIB and HAVE_THEIR_LIB. HAVE_MY_LIB calls
MY_MDL_HAVE_OPENGL and HAVE_THEIR_LIB calls THEIR_MDL_HAVE_OPENGL. *The
same macro is being called twice because it exists under different names*.
Is there some way of addressing this problem other than having the macro
installed with autoconf? I really don't agree that an OpenGL detection
macro is too specialized to warrant such inclusion.
--
Braden N. McDaniel
[EMAIL PROTECTED]
<URL:http://www.endoframe.com>
