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

[Pau Garcia i Quiles]

On Monday 21 May 2007 21:27, E. Wing wrote:

> Hi, a few comments on your Find modules you just submitted.
> 
> 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?

> 
> Also, is there a reason for the CHECK_CXX_SOURCE_COMPILES? It doesn't
> seem necessary to me. I personally like to avoid these things because
> of both performance and also because I always have an eye towards
> cross-compiling and I don't expect this type of thing to be
> trustworthy in those situations until CMake offers true
> cross-compiling support.

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.

That happens with OSG 1.1, we have not tested yet with OSG 1.2.

> As for Lua, the problem with Lua is there isn't really an official way
> to install it. So the first problem is that is not necessarily true
> that the #include is
> #include <lua50/lua.h>
> or
> #include <lua5.1/lua.h>
> 
> There are a lot of permutations that will break this:
> #include <lua5.0/lua.h>
> or
> #include <lua51/lua.h>
> 
> Or simply
> #include <lua/lua.h>
> which is probably the most common occurrence for people who build and
> install Lua themselves.
> 
> In my opinion, the most portable thing is:
> #include "lua.h" and let CMake test all the common permutations. (This
> is what SDL officially recommends because the problem is just as bad.)
> I also like providing for environmental variables for CMake to check
> in case you have a permutation that is not covered.
> 
> 
> Second, Lua 5.0 by default likes to split the standard library
> (lualib) and core (lua) into two separate pieces, so there might be
> two pieces you need to look for assuming the user is using the
> standard library, but is often the case. But it is quite possible they
> get rolled into one piece for convenience. And it is possible they
> don't have the standard library at all (though I expect it to be rare
> on platforms the CMake currently supports as the people to avoid the
> standard library are on embedded platforms with extremely tight memory
> requirements and can't afford ~50k).
> 
> Conversely, in Lua 5.1, the default is to build them as one piece, but
> it should be possible to keep them as two pieces and of course not
> building the standard library at all.

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

Thank you for your comments.

> 
> Again, I'm not a fan of the try compiles (CHECK_LIBRARY_EXISTS), but
> in this case, you could make an argument for it. But it should mainly
> be targeted at finding the standard library in my opinion if used at
> all. I'm also thinking that some optional flags to define before
> calling FindPackage(Lua) might be the better way to go to handle some
> of these situations (like specifying you're using the standard
> library) instead of the try compiles.
> 
> One last question, should these modules be spouting MESSAGE calls by
> default and at all? I was always under the impression that the best
> thing to do is punt to standard CMake behavior here if things are not
> found because it will do the error messaging for you.
> 
> Thanks,
> Eric
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 
> 

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to the amount of work, I usually need 10 days to answer)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20070521/b8956f7c/attachment.pgp