Cannot specify compile definitions for target "SDL2::SDL2" which is not built by this project

[sarcXD]

Hi, I got interested in contributing to this project, and was in the section of building my dev environment. I wanted to report/seek help on this really annoying issue I came across. It doesn't seem to be popular enough to have any posts online either so I'm hoping its easily resolvable. I have also spent a huge chunk of time trying to resolve this myself, going through issues on this repo, as well as any similar ones online (maybe related to cmake or SDL), but found nothing there sadly, most posts were related to using SDL with cmake.

My Environment

• Ubuntu 20.04.3 LTS
• gcc 10.3.0
• cmake 3.19.4

I will first try to highlight all that I have done:

1. Followed the installation steps
2. Made sure I have installed all dependencies
3. Removed and reinstalled the libsdl2-dev* packages (incase I did something wrong)
4. Read and tried to follow through on the troubleshooting section 4.1. I manually passed in my SDL_image location, (although I am not sure if this would be the issue since the script did notify me when SDL2 was not installed on my system, meaning it does detect it in the correct folder, but I might be wrong)

The exact command I used to run this was

./configure -- -Dnyan_DIR=/home/me/Documents/Work/sideProjects/openage-oss-work/nyan/build

I also did use the DSDL2IMAGE_INCLUDE_DIRS flag, and admittedly, I could not exactly tell what I was supposed to point this to, I read the docs but it wasn't clear enough. So, I tried just about everything here, pointing it to where my:

• SDL.h and SDL-image.h files are located
• SDL*.so files are located ( I was just trying everything here)
  These were all the locations where my SDL2 files were installed (I think)

I am posting my entire log for an incase detailed report, before someone asks for it in detail, but I will mention the specific section afterwards to make pinpointing the issue easier.

./configure is a convenience script:
it creates the build directory,  symlinks it,
and invokes cmake for an out-of-source build.

Nobody is stopping you from skipping ./configure and our Makefile,
and using CMake directly (e.g. when packaging, or using an IDE).
For your convenience, ./configure even prints the direct CMake invocation!

         build_type | Debug
       cxx_compiler | g++
          cxx_flags | 
   exe_linker_flags | 
     install_prefix | /usr/local
module_linker_flags | 
shared_linker_flags | 

config options:

          backtrace | if_available
gperftools-profiler | if_available
gperftools-tcmalloc | False
            inotify | if_available
            ncurses | if_available
             opengl | if_available
             vulkan | if_available

bindir:
/home/me/Documents/Work/sideProjects/openage-oss-work/openage/.bin/g++-debug-Oauto-sanitize-none/

invocation:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS='' -DCMAKE_EXE_LINKER_FLAGS='' -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_MODULE_LINKER_FLAGS='' -DCMAKE_SHARED_LINKER_FLAGS='' -DCXX_OPTIMIZATION_LEVEL=auto -DCXX_SANITIZE_FATAL=False -DCXX_SANITIZE_MODE=none -DWANT_BACKTRACE=if_available -DWANT_GPERFTOOLS_PROFILER=if_available -DWANT_GPERFTOOLS_TCMALLOC=False -DWANT_INOTIFY=if_available -DWANT_NCURSES=if_available -DWANT_OPENGL=if_available -DWANT_VULKAN=if_available -Dnyan_DIR=/home/me/Documents/Work/sideProjects/openage-oss-work/nyan/build /home/me/Documents/Work/sideProjects/openage-oss-work/openage

(now running cmake:)



 ___  ______ _______ _______ ___
|  _)/ _____|_______|_______|_  |
| | ( (____  _____      _     | |    ___  ____  _____ ____  _____  ____ _____
| |  \____ \|  ___)    | |    | |   / _ \|  _ \| ___ |  _ \(____ |/ _  | ___ |
| |_ _____) ) |        | |   _| |  | |_| | |_| | ____| | | / ___ ( (_| | ____|
|___|______/|_|        |_|  (___|   \___/|  __/|_____)_| |_\_____|\___ |_____)
                                         |_|                     (_____|

Welcome to the SFT technologies computer-aided openage build system!

You have chosen, or been chosen, to attempt the daring task of building openage.
If you have installed all the dependencies that are conveniently listed in
[doc/building.md], this _might_ just work!

If it doesn't, consider reporting the issue: https://github.com/SFTtech/openage
Or ask for help:
  * Matrix: #sfttech:matrix.org
  * IRC:    #sfttech on libera.chat

========================================================
-- Set PROJECT_VERSION from git.
CMake Error at libopenage/CMakeLists.txt:51 (target_compile_definitions):
  Cannot specify compile definitions for target "SDL2::SDL2" which is not
  built by this project.


-- Could NOT find GCCBacktrace (missing: GCCBacktrace_LIBRARIES GCCBacktrace_INCLUDE_DIRS) 
-- optional dependency is unavailable: backtrace
-- Could NOT find GPerfTools (missing: GPERFTOOLS_LIBRARIES GPERFTOOLS_INCLUDE_DIR) 
-- optional dependency is unavailable: gperftools-profiler

cython module
	run                                                 [embedded interpreter] [noinstall]
	openage.cython_check
	openage.cabextract.lzxd
	openage.cabextract.cabchecksum                      [standalone]
	openage.convert.processor.export.terrain_merge
	openage.convert.processor.export.texture_merge
	openage.convert.service.export.interface.visgrep
	openage.convert.service.export.opus.opusenc
	openage.convert.service.export.png.binpack
	openage.convert.service.export.png.png_create
	openage.convert.value_object.read.media.slp
	openage.convert.value_object.read.media.smp
	openage.convert.value_object.read.media.smx
	openage.cppinterface.exctranslate
	openage.cppinterface.exctranslate_tests
	openage.cppinterface.pyobject
	openage.cppinterface.setup_checker
	openage.cvar.cvar
	openage.event.demo
	openage.game.main_cpp
	openage.log.log_cpp
	openage.main.main_cpp
	openage.main.tests
	openage.renderer.renderer_cpp
	openage.renderer.tests
	openage.testing.cpp_testing
	openage.testing.misc_cpp
	openage.util.filelike.cpp
	openage.util.fslike.cpp
	openage.versions.versions

enabled options:
	inotify
	ncurses
	opengl
	vulkan

disabled options:
	backtrace
	gperftools-profiler
	gperftools-tcmalloc

openage 0.4.1.694

   version string | v0.4.1-694-g6e5546b7
         compiler | GNU 10.3.0
           python | 3.6.10
       build type | Debug
         cxxflags |  -fdiagnostics-color=auto  -Wall -Wextra -pedantic -Wsuggest-override
 build type flags | -g -Og
        build dir | /home/me/Documents/Work/sideProjects/openage-oss-work/openage/.bin/g++-debug-Oauto-sanitize-none
   install prefix | /usr/local
py install prefix | /usr/local/lib/python3.6/site-packages

Incase the detailed log is too much to go through, this is what I think the exact issue I am coming across is

CMake Error at libopenage/CMakeLists.txt:51 (target_compile_definitions):
  Cannot specify compile definitions for target "SDL2::SDL2" which is not
  built by this project.

and the line in the libopenage/CMakeList.txt is

find_package(SDL2 CONFIG REQUIRED)
target_compile_definitions(SDL2::SDL2 INTERFACE SDL_MAIN_HANDLED)
find_package(SDL2Image REQUIRED)

I don't exactly know cmake well enough (or at all) and there wasnt any thing related to this exact line that I could use to figure out what exactly went wrong. I am assuming things in cmakelist or the configure file aren't necessarily meant to be changed, so the issue is probably still related to my setup, I'm just having a tremendous amount of trouble figuring out what exactly I am doing wrong.

I also saw that the .bin/g++-debug-Oauto-sanitize-none/CMakeCache.txt contains what is probably the cache for the cmake run, and well, these are the variables that its using for my sdl2 config

SDL2IMAGE_INCLUDE_DIRS:PATH=/usr/include

//SDL2 library
SDL2IMAGE_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libSDL2_image.so

//The directory containing a CMake configuration file for SDL2.
SDL2_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/SDL2

I would really appreciate if someone who knew this problem well enough, could help, because at this point I've spent far too long enough on this to just abandon it, and have spent enough time on this, that its driving me crazy not knowing anything regarding what might be going wrong here.
I would also like to thank all the contributors for the existing detailed and rather welcoming guides in advance, since that was what really made it easy for me to try and get started with this in the first place.
Apologies if I made a mistake somewhere in setting up that I have overlooked, and hopefully this was enough info to help whoever is willing to look at this issue.

Edit

Posting my error logs as requested (uploaded them since they're quite large) CMakeError.log CMakeOutput.log

[heinezen]

Thanks for the detailed description so far. You don't always get that in bug reports :)

Can you post the cmake log files, too? They should be located in bin/CMakeFiles/CMakeError.log and bin/CMakeFiles/CMakeOutput.log. Maybe we can figure out what's wrong when looking at them.

[sarcXD]

thank you :)
I have edited my post to upload the files you requested, hope it helps

[heinezen]

@sarcXD I don't see the error message in the log... which is odd.

Have you cleaned the build directories before running configure again? You can do that by running

make cleanbuilddirs

in the source directory. This will clean the cmake cache of the previous unsuccessful builds. Sometimes this helps eliminating errors.

Other things you can try:

1. I see you are using a standalone cmake version that's newer than the version from the Ubuntu package repositories. You could try using the cmake package from the Ubuntu 20.04 repos and see if that changes anything. The path to the cmake binary you want to use can also be specified by the --cmake-binary flag of the configure script. I already tried building openage with the binaries of cmake version 3.19.4 (that you used) and it didn't produce any errors, but maybe there's something weird about your cmake build.
2. Try ./configure --download-nyan instead of building nyan separately (configure will handle it for you). Not sure if that changes anything, but it's the easiest way to get a "standardized" build.

[sarcXD]

@heinezen so, I did try to:

1. run make cleanbuilddirs
2. removed firstly, all cmake versions I had, made sure to remove all files
   2.1 I installed the one ubuntu uses, tried that and didn't work 2.2 I tried 2 of the latest releases by downloading and installing the precompiled versions, one at a time and tried with them, I get the same error for that.

The one thing that I did see, was related to this #1407 and so just to test it out, and I'm not sure if the build is still erronous, I locally tried to run the configure script on the set of commands that this PR changed, and that did compile. Then I continued with the make command, which failed at the point where it failed to find my SDL.h file. I figured this would be similar to it not finding my sdl directly, so I proceeded to pass in the flag DSDL_INCLUDE_DIR Which helped somewhat, and I ran into a bunch of undefined reference to SDL_* errors.

Now I don't primarily know if the commands I reverted to would have caused this to fail either way, but could it be possible that cmake isn't picking up my correct SDL2 library location, I don't know much about how cmake works, so I am just making a guess.
Is there a flag I can use (apart from the SDL2Image flag, because I think the image is being picked up) to make sure it finds the SDL file? I wanted to test if sdl was installed properly, and so I used a test file that included the SDL header and that worked fine as well, so Ive just about tested everything that I thought could be a problem, and also abit out of ideas on it now :( I have tried to remove cmake both the one installed on ubuntu, and the one I did, I proceeded to try every way of installing cmake I found, downloading from the apt store, using a precompiled binary and also building from source, so that is also abit unlikely to be problematic, of course I am not entirely sure there.
Again, sorry I can't provide more than this but I hope there is something helpful in what I mentioned.

[sarcXD]

Hi, so after extensively looking into this I figured out the problem with this exact bug. While this has been extensively discussed and fixed here. The main crux of this was that the issue was with the statement SDL2::SDL2. To be specific, this exact functionality, presently whilst works for a bunch of OS, does not work for the sdl version available for Debian, and thus Ubuntu. This was fixed by a user in a PR, but since the repos aren't updated, I shall just mention the recommended step for now (I am facing an issue in the make stage, so once I am able to resolve that, I could just add this in the troubleshoot section as a PR):

1. We need to get the latest sdl files, the only way is to compile them ourselves.
2. We also need to get the latest sdl images and compile those ourselves as well.
   While not the best way, for those with systems that aren't yet updated, this seems to be the only way. The steps to build will be available on each of the respective tools online documentation.
   I shall mention my other issue incase I keep finding myself stuck there as well, but so far hope this helps in case anyone does indeed find themselves stuck :)

[TobiasFP]

If you send me a bash dump i can dockerise the build process of the libraries

[sarcXD]

@TobiasFP can you please explain abit more on how and what specifically I need to send you with regards to the bash dump? I have managed to resolve all the issues I was facing and have set up the project now.

[sarcXD]

@heinezen i've added an entry in the troubleshooting doc in a fork I made, and created a pull request for it #1434
Hope it helps :)

[heinezen]

@sarcXD Thanks for diggng so deep! Looks like the old SDL version is indeed the problem.

[TheJJ]

thanks for your findings! first thing i wonder why it does work on our ci then. can you investigate, what target name is available for use? if there is an alternative, we can check for its existence and use it instead. i don't think its worth pulling sdl sources manually just for this.

[sarcXD]

@TheJJ I can take a further look into this,
a. I have 1 or 2 reasons that come to mind but need to look into the ci setup to understand why it would/would not work. b. As for alternatives to the current approach id need to look into the options CMake allows us, so once I've done a, I can check this.

[heinezen]

@sarcXD The solution could be a simple

if(<SDL target exists>) 
    <do the normal stuff>
    ...
else()
    <use workaround target definition>
    ...
endif()

until the changes arrive in the LTS repos.

[duanqn]

@sarcXD Thanks for the great analysis! Our Ubuntu CI: https://github.com/SFTtech/openage/actions/workflows/ubuntu-21.04.yml We installed libsdl2-dev from apt. The corresponding file is located at .github/workflows/ubuntu-21.04.yml . Looks like somehow we did not catch this issue. Maybe Ubuntu upgraded the SDL package version?

So -- the conclusion is that we should use the latest version (2.0.16 currently) of SDL, right?

[heinezen]

@duanqn As far as I can see from the forum thread, SDL2 2.0.12 is the version that fixed the issue by including SDL2::SDL2 in the alternative cmake config.

[sarcXD]

@duanqn yes, so based on the ubuntu package repo, these are the versions each release uses:

• ubuntu focal (20.04) -> sdl 2.0.10
• ubuntu groovy (20.10) -> sdl 2.0.12 (as heinezen mentioned, this has the fix)
• ubuntu hirsuite (21.04) -> sdl 2.0.14 ( Current CI/CD base )

@TheJJ So, this is why the ci workflow works fine

[sarcXD]

@heinezen I am trying to set it up as you suggested and based off of what i saw as suggested from the link I posted. The steps I follow are:

1. trying to use SDL2::SDL2 if available.
2. If not I try to use the findSDL2.cmake file using find_package.
3. If that does not work I try to use FindPkgConfig which is what a user had suggested. For this I had to include my sdl2,sdl2 image.pc file paths. But this is what I eventually fallback to and what works. I'm adding a sample, or should I create a PR from this. I wanted to get a basic review beforehand.

find_package(SDL2 CONFIG REQUIRED)
if(SDL_FOUND)
	target_compile_definitions(SDL2::SDL2 INTERFACE SDL_MAIN_HANDLED)
	target_link_libraries(libopenage PRIVATE SDL2::SDL2)

else()
	message("-- Could NOT find SDL2 config. Trying to use findSDL2.cmake")
	find_package(SDL2 REQUIRED)
	if(SDL_FOUND)
		message("-- Could NOT find SDL2 config. Trying to use findSDL2.cmake - found")
	else()
		message("-- Could NOT find SDL2 using findSDL.cmake. Trying to use FindPkgConfig")
		INCLUDE(FindPkgConfig)
		PKG_SEARCH_MODULE(SDL2 REQUIRED sdl2)
		if(SDL_FOUND)
			message("-- Could NOT find SDL2 using findSDL.cmake. Trying to use FindPkgConfig - found")
		endif()
	endif()
endif()

[duanqn]

@sarcXD Thanks for the great work! Just my two cents -- do we want to add minimum version 2.0.12 for SDL2? This looks simpler and I think 2.0.12+ will be generally available in the near future, considering Ubuntu 22.04 will be released soon. @TheJJ Also, there was a findSDL2.cmake before I deleted it in #1407 . It might be helpful if we want to support legacy versions of SDL2.

[heinezen]

@duanqn Well, "soon" is still a rather long time in this case :D But I think requiring SDL 2.0.12 would be okay in this case, although it's not great to up the depedency just because of cmake problems. If we can find an easy workaround that works similarly to what @sarcXD proposed above, then we should also try to support older versions of SDL2.

[heinezen]

We no longer require SDL2 so this should be solved!