[CMake] Re: FindSDL.cmake and mingw / msys

[E. Wing]

> 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