[CMake] Re: FindLua50.cmake, FindLua51.cmake, FindOpenThreads.cmake

[E. Wing]

> From: Pau Garcia i Quiles <pgquiles at elpauer.org>


> > For OpenThreads, I'm fairly close to the OpenThreads project and I've
> > been working on a formal find script for CMake. (I thought one of my
> > older scripts was already in the distribution too.) Our users have
> > found a lot of interesting problems, so the final script will
> > hopefully be extremely robust.
>
> Great! Have you got a release date yet?

So OSG is ramping up for a release by "end of May or early June". So
I'm hoping to get all this stuff finalized for the release. Obviously,
it won't be syncronized with a CMake release, but that will give us
time to perfect the module further.


> > Also, is there a reason for the CHECK_CXX_SOURCE_COMPILES? It doesn't
> > seem necessary to me.
>
> Actually, yes, there is.
>
> We are usign OpenThreads with OpenSceneGraph in a project where we also use
> a
> propietary database (InterSystems Caché) which has a #define which breaks
> OpenThreads. It needs a bit of careful tuning to make OSG and ISC Caché both
> work on the same project and if you do not add the magic in your program,
> compilation fails and it's not exactly intuitive what is failing. That's why
> I want to make sure OpenThreads include files and libraries are not only
> available but they do work.

So a couple of questions on this.
So I'm curious, how does the CHECK_CXX_SOURCE_COMPILES help avoid this
problem? I'm not very familiar with the call, but it would seem to me
that the result of
CHECK_CXX_SOURCE_COMPILES would not necessarily be the same result of
compiling your real program.

Second, how does the #define break OpenThreads? What is this #define
do? Is there a common #define being used by both libraries. If so, we
might be able to rename the ones in OpenThreads. Or is there some
other source level fix that can be done. Since the next release is
coming soon, if you can isolate the problem and submit a patch soon,
you might be able to get this fixed permanently.

(Lua)
> Interesting, I had assumed the Ubuntu/Debian installation directories were
> the
> standard ones. I'll change the scripts according to what you said.

Actually on second recollection, I think the Lua Makefile likes to
install by /usr/local by default (without a lua*/ subdirectory). And
certainly Windows users can/will drop it anywhere they see fit. So
again, #include "lua.h" is the best strategy.

Thanks,
Eric