From: Ian S. <ian...@st...> - 2002-08-16 15:16:19
|
Hi, Summary: Let's tidy up the config.cmake/Modules directory. Amitha and I have write access to the CMake repository, where we can put much of the extra functionality in our own Modules directory. Detailed: Why do we have lots of extra FindXXX.cmake files in config.cmake/Modules that don't really do anything VXL specific? In particular I'm thinking of FindQT.cmake, FindMPEG.cmake, FindNativeJPEG.cmake, etc. It appears to me that 1. these files either contain unnecessary functionality e.g FindMPEG.cmake merely appears to replicate HAS_MPEG, MPEG_INCLUDE_PATH with HAS_NATIVE_MPEG, NATIVE_MPEG_INCLUDE_PATH) or 2. The functionality in them would be better move to CMake's own modules directory. e.g FindQT.cmake does useful stuff like figures out which other libraries are need by qt. Having our own FindQT.cmake is particularly inappropriate since we don't have any qt code in the vxl repository. I got to thinking about this because CMake is now powerful enough that we don't have to use the complex and unpleasant CMakeListsLink.txt files anymore (thanks Amitha.) In a similar vien, the more powerful ability to use CMake variables should now mean that we do not need to use so many of our own .cmake files. Since CMake is now on a release schedule, we can't can't do this properly until the next release. But I think it is worth starting now. Ian. |
From: Amitha P. <pe...@cs...> - 2002-08-16 16:09:52
|
The thing that worries me about using CMake's modules is the lack of consistency. For example, CMake's FindGLUT provides GLUT_INCLUDE_PATH and GLUT_LIBRARY; FindGTK _only_ checks for libgtk, but provides GTK_INCLUDE_PATH, GTK_LIB_PATH, GTK_GLIB_INCLUDE_PATH; FindJPEG provides NATIVE_JPEG_INCLUDE_PATH and NATIVE_JPEG_LIB_PATH. Our modules, on the other hand, have a much more consistent interface. As far as the user is concerned, a module FindABC will set HAS_ABC to yes or no, and if yes, will set ABC_INCLUDE_PATH and ABC_LIBRARIES--each of the latter two could be a set of values--and finally, may define preprocessor symbols necessary to compile with ABC. Clearly, the CMake modules were developed on an ad-hoc basis by different people, and hence the differences. It is possible to use the power of the new CMake to clean up those modules too. However, I am under the impression that those modules are heavily used by VTK. I don't know how much resistance there will be to change the functionality of those modules. All this said, I think a clean up and merge would be good, provided the CMake authors (and therefore VTK and ITK authors) are amenable. The next release of CMake should be 1.6. I believe they are planning some grand new features like loadable modules for CMake commands. I agree with you, Ian, that should begin now, so we can influence (and be influenced by) the direction of CMake. Amitha. On Fri, Aug 16, 2002 at 04:17:25PM +0100, Ian Scott wrote: > Hi, > > Summary: > Let's tidy up the config.cmake/Modules directory. Amitha and I have write > access to the CMake repository, where we can put much of the extra > functionality in our own Modules directory. [...] > > Ian. > |