CMake: Link to debug/release libraries in VS 2010

[Laurent]

Make it intuitive for Linux developers and choose the desired configuration if possible, and the other if not. This however doesn't allow a Windows developer to enforce the desired configuration. But worse is the fact that if the configuration is missing, there will occur a silent error on Windows.

The solution to this is simple: I should modify SFML so that developers can safely mix configurations on all OSes and compilers. However it requires major modifications to the code and I don't know if it's going to happen one day...

By the way, how is a single missing component (e.g. sfml-window) handled, when the rest of the same configuration is available? Is the library just missing in the list, or does the variable contain the "-NOTFOUND" postfix? The latter would probably be the better choice because the error is immediately recognized.

I don't know, it's handled by CMake (but I'll probably have to handle it myself if I apply these modifications).
I think -NOTFOUND is appended, and yes it's probably the best solution.

[Nexus]

The solution to this is simple: I should modify SFML so that developers can safely mix configurations on all OSes and compilers.

From what I know in Visual Studio, mixing different C runtime libraries (like /MD and /MDd) is problematic unless you limit the interfaces to a few CRT-independent types, which can be a unpleasant limitation. I doubt this is the best way to go... Windows developers should be aware of linking the corresponding release/debug libraries. The problem arises if they think they are, but CMake misleads them

The other FindSFML.cmake adaptions look good so far, I have to test them in action as soon as you commit the modifications

[Laurent]

The other FindSFML.cmake adaptions look good so far, I have to test them in action as soon as you commit the modifications

So should I commit my initial strategy (which is already implemented, just not tested)? Or should I change something according to our discussion?

[Nexus]

Good question. I must admit the thought of linking the wrong configuration on Windows so easily doesn't really please me. But you have convincing points, the way of Qt seems to be much better than I first thought.

However it would be nice if there were at least a more or less simple option to perform additional checks on user side. Currently I see no way to ensure correct debug/release libraries, except to parse the FindSFML variables. Maybe a SFML_RELEASE_FOUND and SFML_DEBUG_FOUND which are true when all components of the corresponding configuration are available. I have such a use case in mind (it would primarily apply to MinGW):

Code: [Select]

# Note: multi-configuration generators are already covered by
# SFML_LIBRARIES which contains "optimized" and "debug" keywords

if(WIN32 AND NOT CMAKE_CONFIGURATION_TYPES)
if(NOT SFML_DEBUG_FOUND AND CMAKE_BUILD_TYPE STREQUAL "Debug")
message(FATAL_ERROR "Trying to link SFML debug libraries which haven't been found")
elseif(NOT SFML_RELEASE_FOUND AND CMAKE_BUILD_TYPE STREQUAL "Release")
message(FATAL_ERROR "Trying to link SFML release libraries which haven't been found")
endif()
endif()
What do you think about that? Do you see a simpler solution to address this problem, while keeping your initial strategy?

[Laurent]

I have to think more about this. SFML_XXX_DEBUG_FOUND (same for RELEASE) seems to be a good solution, just need to check if there's something simpler.

In the meantime I commit the file so that you can already test it.

[Nexus]

SFML_XXX_DEBUG_FOUND (same for RELEASE) seems to be a good solution, just need to check if there's something simpler.

I thought more about SFML_DEBUG_FOUND if all debug components are found. It has a more "high-level" value for the user.

Additionally, SFML_XXX_DEBUG_FOUND is an option for fine tweaking. I don't know how many variables you want to define, that's why I haven't proposed it.

[Laurent]

You're right, I answered too quickly. SFML_DEBUG_FOUND is all we need -- indeed I'd like to keep the number of variables as low as possible

[Nexus]

Could you include SFML_DEBUG_FOUND and SFML_RELEASE_FOUND in the commit?

[Laurent]

Too late :wink:

Like I said, I'd like to think more about it before adding these variables.

[Nexus]

Okay. I understood "SFML_DEBUG_FOUND is all we need" in a way that you changed your opinion. But of course it's better if you think about it without hurry. You also have to consider I'm not an expert at this topic (cross-platform linking and CMake), so I might overlook things.

I wouldn't mind if other users tested the FindSFML modifications and expressed their opinion, too

[Nexus]

A first problem I've come across: SFML_LIBRARIES contains a leading whitespace and doesn't use ; as library separator, which is a problem for paths containing spaces. You can fix this if you change the line

Code: [Select]

set(SFML_LIBRARIES "${SFML_LIBRARIES} ${SFML_${FIND_SFML_COMPONENT_UPPER}_LIBRARY}")to

Code: [Select]

set(SFML_LIBRARIES ${SFML_LIBRARIES} "${SFML_${FIND_SFML_COMPONENT_UPPER}_LIBRARY}")

[Laurent]

Thanks. Lists in CMake always confuse me :?

[Laurent]

It's fixed.

I'll probably add the SFML_DEBUG_FOUND and SFML_RELEASE_FOUND variables in a later commit.