On 7. Oct 2010, at 9:16, Daniel Pfeifer wrote: > your changes in revision 4930 "CMake: file renaming for consistency" are > just wrong: The naming convention for CMake files is either > * the file ending .cmake or > * the name CMakeLists.txt.
I wasn't aware of this convention. I'll rename them, but not to config.cmake since it was driving me mad due to the name being close to config.cpp. > Another problem has been introduced in config.cmake: > I wrote it that way, that it generates a file defines.h.in that is > eventually configured to defines.h. The reason why I don't generate > defines.h directly, is that I want defines.h not to change unless the > definitions actually changed (to reduce recompilation after a cmake > run). > > I don't care who did it, but the name defines.h.in has been changed to > something stupid. I had my reason to do it like this. Was there a reason > to break it? Me again, and I had my reasons as well. The reason is that defines.h should not be generated. It selects automatically defines<System>.h, which enables the same set of headers for e.g. Linux and Windows. So I guess CMake should still generate defines.h.in which should be configured to defines<System>.h. Do you agree? Can you do that? Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
