Hello all, so I've been working with SFML and GLEW in MSVC 2010 and have had very few issues (despite using static libraries for both, which can be an issue). I'm able to compile and run and have no linking issues or anything. However, I have plenty of friends whom I'd like to play my game that use Linux exclusively (Macs also for that matter). So, I wanted to use CMake to allow me to compile on several different platforms. I followed along the articles written here (http://www.gamedev.net/page/resources/_/technical/general-programming/cross-platform-test-driven-development-environment-using-cmake-part-1-r2986). I put together a successful CMakeLists.txt and it gets through fine, finding my GLEW and SFML directories. However, I get GLEW linking errors when I try to compile. It compiles the game fine, but when it gets to linking it cannot get past this GLEW stuff. At first I just thought it was the GLEW in SFML conflicting with my GLEW, but no matter what order I put the libraries in, I have the same issue. I'm hoping that since I can compile with MSVC2010 .sln file, but not with this, it's just a configuration issue. Hopefully someone here with experience with these 3 systems can give me some advice. Here's my CMakeList.txt:

cmake_minimum_required(VERSION 2.6)
project(BattleMap)

include_directories(
	"${PROJECT_BINARY_DIR}"
	$ENV{GLM_ROOT}
	$ENV{RAPIDXML_ROOT}
	$ENV{GLEW_ROOT}/include
)

set(EXECUTABLE_NAME "BattleMap")
set(BattleMap_SRCS	
	battlemap.cpp
	battlemap.h
	
	bufferobject.cpp
	bufferobject.h
	
	camera.cpp
	camera.h
	
	globals.h
	
	vertices.h
	
	texture.cpp
	texture.h
	
	vao.cpp
	vao.h
	
	supertexture.cpp
	supertexture.h
	
	shaderprog.cpp
	shaderprog.h
	
	scene.cpp
	scene.h
	
	submapscene.cpp
	submapscene.h
	
	mapscene.cpp
	mapscene.h
	
	mousepointerscene.cpp
	mousepointerscene.h
	
	application.cpp
	application.h
	
	main.cpp
)
	
add_executable(${EXECUTABLE_NAME} ${BattleMap_SRCS})

IF (WIN32)
	MESSAGE("IS Win32")
ELSE (WIN32)
	MESSAGE("NOT Win32")
ENDIF (WIN32)

set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})

IF (WIN32)
	add_library(glew_static STATIC IMPORTED)
	set_target_properties(glew_static PROPERTIES
		IMPORTED_LOCATION $ENV{GLEW_ROOT}/lib/glew32s.lib)
	target_link_libraries(${EXECUTABLE_NAME} glew_static)
ELSE (WIN32)
		find_package(GLEW REQUIRED)
ENDIF (WIN32)



# Detect and add SFML
find_package(SFML 2.0 REQUIRED system window graphics)
#find_package(GLEW REQUIRED)

if(SFML_FOUND)
  include_directories(${SFML_INCLUDE_DIR})
  target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()

#if(GLEW_FOUND)
#	MESSAGE("GLEW include path found!")
#	include_directories(${GLEW_INCLUDE_PATH})
#	target_link_libraries(${EXECUTABLE_NAME} ${GLEW_LIBRARY})
#endif()

# Install target
install(TARGETS ${EXECUTABLE_NAME} DESTINATION bin)

Some of the GLEW stuff commented out is just me trying different orders for CMake. If more information would be helpful, I'm more than happy to provide it. Thanks ahead of time.

This is unfortunately a pain in the butt, I went through the problems myself recently. The simple answer is to look at the updated environment which is part of my next article, you can find the source at: https://code.google.com/p/a8u-tutorial-sources/. (Under the Game directory, not the "environment" one, that's out of date.) The SFML and XO applications link against SFML 2 statically on all three platforms. In your above cmake code you are likely linking against shared objects on Linux which can cause other problems. I'll take a further look into your code listfile when I move downstairs and get on my laptop and see if I can't point out specific issues.

Oh, an important item of note. SFML links against glew already, so if you link statically as I do, don't bother trying to link glew, it's already there.

Hmm... see it seems like it can't find a GLEW to link against, despite linking it or not... here's some of the linking output:

CMake is not really the problem here, mixing dll's, static libs and such on Window's is being a pain in the butt for you. Notice in your link errors the prefix portion: __imp__. That means something is still attempting to use the glew headers without having defined GLEW_STATIC. Given this is windows, I'd suggest taking a look at the updated CMake files which deal with all this nonsense. I'm going to take a look at your listfile in more detail now, give me about 15-20 minutes.

First pass notes, obviously I'm only able to poke at this so much without having a better idea of your setup. Basically you should not have to include the glew stuff at all for Window's, just point at the SFML glew include directory (in order to keep the version sync'd) in the extlibs dir. The other problem is not setting the static flag for SFML before the find. Hope this gets you going forward, let me know what goes wrong next. :)

#<snippity snip>

set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})

IF (WIN32)
#   Don't do this, glew is already statically linked as part of SFML 2.0.
#   It is probable that CMake strips this all out anyway, just be safe.
#   add_library(glew_static STATIC IMPORTED)
#   set_target_properties(glew_static PROPERTIES
#       IMPORTED_LOCATION $ENV{GLEW_ROOT}/lib/glew32s.lib)
#   target_link_libraries(${EXECUTABLE_NAME} glew_static)
ELSE (WIN32)
    # NOTE: this will give you the shared object on other platforms.
    # not a problem, just important to keep in mind.
        find_package(GLEW REQUIRED)
ENDIF (WIN32)

# Detect and add SFML
# You need to tell this to use static libs, probably only on Windows though:
IF( WIN32 )
  SET( SFML_STATIC_LIBRARIES TRUE )
ENDIF()

find_package(SFML 2.0 REQUIRED system window graphics)
#find_package(GLEW REQUIRED)

if(SFML_FOUND)
  include_directories(${SFML_INCLUDE_DIR} )
  target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()

#if(GLEW_FOUND)
#   MESSAGE("GLEW include path found!")
#   include_directories(${GLEW_INCLUDE_PATH})
#   target_link_libraries(${EXECUTABLE_NAME} ${GLEW_LIBRARY})
#endif()

# Install target
install(TARGETS ${EXECUTABLE_NAME} DESTINATION bin)

I've still got the same problem. I'm wondering if this is due to me using a different version of GLEW as SFML. I'm using 1.9.0, I don't know what SFML uses, but could that be an issue?

... nope, that is not the issue. Even if I add {SFML_ROOT}/extlib/headers to my includes, it gives me the same linking error. I'm not sure what the difference could possibly be.

Oops, forgot one other item. You need to add:

ADD_DEFINITIONS( -DSFML_STATIC -DGLEW_STATIC )

To your application.. Without this you are trying to use the dynamic includes.

Well, that changes things, but nothing good unfortunately. It just tells me that I defined GLEW_STATIC in more than one file. Which is nice to know, but not helpful. It still has the same problem once I get to linking. This is pretty frustrating...

I also want to say, thank you so much for your help. Even though I haven't been able to resolve the issue, I really appreciate that you are helping me so much.

Well, for the moment, I'm not sure. Probably you need to remove the glew static define since that is obviously not needed. But I'm not sure how to fix the link error, that is almost surely an indication of glew static not being defined somewhere and as such trying to use declspec'd versions incorrectly, but I can't think of anything we've missed right now. I'll go poke around in my codebase and see if I can find anything I did there that hasn't been covered yet.

One thing you might try is to remove any inclusions of glew/gl headers and only use the <SFML/OpenGL.hpp> header just in case there is an include order conflict somewhere.

As to helping out, no worries. Been fighting with an SFML integration problem tonight trying to test the Spine runtimes, might use them for 2D stuff, just an experiment but it doesn't want to work correctly as of yet.