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. 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. 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. 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@cmake.org http://www.cmake.org/mailman/listinfo/cmake
