Maybe this could be implemented in a major release of CMake, thus developers would be aware that changes are required to their scripts. As soon as it is advertized enought, it's ok.
I'm more inclined to leave the current behavior, and when SDL 1.3 finally rolls around, try a fresh start then since we'll most likely need a new script for that anyway.
Currenly, under Windows, when I click on the configure button in CMAKE, it says: - I did not found "qmake.exe", - so I set the value for the QMAKE_EXECUTABE variable, - click on configure one more time.
So we have nothing to do with QMake. Whatever happens there is outside our domain. > - It says, "I did not found SDLMAIN_INCLUDE, SDLMAIN_LIBRARY,
SDLIMAGE_INCLUDE, SDLIMAGE_LIBRARY" - I set those variables, - click on configure one more time.
So I need more details about how CMake does this. I don't understand how CMake determines which ones to nag you about. The nags I get are different than yours.
And what about calling that variable SDL_LIBRARY_DIR (with for example the value "c:\My project\lib") and deducing from that all the other variables.
No, deduction can fail. There may be a case where SDLmain and SDL are located in different directories. There is also the case that the libraries are not named what we expect. Thus, each one requires their own field to handle these cases, as they do now. And this is the reason for the complexity. Just in case we do screw up something, SDL_LIBRARY is generated and appears in final form with everything clear and present in the CMakeSetup GUI. So if you need to edit something, that is supposed to be the only thing you modify.
LINK_LIBRARIES(${SDL_LIBRARY} ${SDLMAIN_LIBRARY})
LINK_LIBRARIES is obsolete. You should be using TARGET_LINK_LIBRARIES. Also, the line should only be: TARGET_LINK_LIBRARIES(${SDL_LIBRARY}) The reason for all the script complexity is that everything you need gets rolled into that single variable. There are platforms and cases where SDLMAIN_LIBRARY is not used or does not exist. So the intent was to hide this fact away. And we also roll the platform specific flags like -pthread, the MinGW flag that started this thing, or whatever which is another detail most people won't know all the permutations. And in some cases, order matters or the build will fail. Providing a single variable that has the order correct helps prevent people from encountering this problem. The SDLMAIN_LIBRARY should have been a TEMP/BOOTSTRAP variable too, because if you modify it after the SDL_LIBRARY variable does get generated, then later changes to SDLMAIN_LIBRARY will not synchronize with SDL_LIBRARY. -Eric _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake