search

RobertBeckebans / RBDOOM-3-BFG

Doom 3 BFG Edition source port with updated DX12 / Vulkan renderer and modern game engine features
https://www.moddb.com/mods/rbdoom-3-bfg
GNU General Public License v3.0
1.38k stars 247 forks source link

commit 988420c breaks Arch Linux SDL2 #469

Closed noabody closed 1 year ago

noabody commented 4 years ago

Reporting a bug? Please make sure you've given the following information - thanks!

Operating system and version: Manjaro Linux 20.0

Is this for single player or multiplayer? Build issue

Description of the bug (and if possible, steps to reproduce the bug): commit 988420c breaks Arch Linux build. ${SDL2_INCLUDE_DIRS} and ${SDL2_LIBRARIES} return no value.

What did you expect to happen instead? Expected SDL2 link libraries and includes to be available during compilation. SDL.h not found.

This patch solves the problem and the resolution was expanded by a sister report I made regarding OpenJediAcademy. https://github.com/JACoders/OpenJK/issues/1034

diff --git a/neo/CMakeLists.txt b/neo/CMakeLists.txt
index 1a36eef6..fcb2c88e 100644
--- a/neo/CMakeLists.txt
+++ b/neo/CMakeLists.txt
@@ -1599,6 +1599,8 @@ else()

        if(SDL2)
            find_package(SDL2 REQUIRED)
+           get_target_property(SDL2_INCLUDE_DIRS SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)
+           get_target_property(SDL2_LIBRARIES SDL2::SDL2 IMPORTED_LOCATION_NOCONFIG)
            include_directories(${SDL2_INCLUDE_DIRS})
            set(SDLx_LIBRARY ${SDL2_LIBRARIES})
        else()
coldtobi commented 4 years ago

What version of SDL2 do you have in Manjaro linux? (it should be Debian based, but only recently there was a new enough SDL2 in Debian. Might be that you need a newer SDL…)

noabody commented 4 years ago

Manjaro Lysia 20.0 and its SDL2 version is 2.0.12 https://www.archlinux.org/packages/extra/x86_64/sdl2/

coldtobi commented 4 years ago

This seems to be an issue with either

Here, in Debian, it builds fine with 2.0.10… Maybe you're seing https://bugzilla.libsdl.org/show_bug.cgi?id=4116?

noabody commented 4 years ago

That's it alright but the Debian solution looks like a hack.

Arch builds SDL2 with almost a pure vanilla config Arch SDL2 PKGBUILD The only change they're making is this:

Debian isn't packaging all of the config files libsdl2-dev_2.0.10 eoan, just this one:

sdl2-config.cmake

# sdl2 cmake project-config input for ./configure scripts

set(prefix "/usr") 
set(exec_prefix "${prefix}")
set(libdir "${prefix}/lib/x86_64-linux-gnu")
set(SDL2_PREFIX "/usr")
set(SDL2_EXEC_PREFIX "/usr")
set(SDL2_INCLUDE_DIRS "${prefix}/include/SDL2")
set(SDL2_LIBRARIES " -lSDL2")
string(STRIP "${SDL2_LIBRARIES}" SDL2_LIBRARIES)

While that does export the proper variable for backward compatibility it doesn't make sense for Debian to create a hack, then advocate that to developers. If they want to promote pure CMake language, as SDL2 appears to be doing, then that would be okay.

I'm a hobbyist so I make my own packages. Arch developers are beginning to make patches as was done for OpenJK: sdl2-cmake.patch

This isn't really a solution as was noted in https://bugzilla.libsdl.org/show_bug.cgi?id=4116.

For my own purposes, I prefer a targeted perl in-line replacement in my PKGBUILD:

perl -pi -e 's|(find_package\(SDL2 REQUIRED\).*$)|\1\n\t\t\tget_target_property(SDL2_INCLUDE_DIRS SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)\n\t\t\tget_target_property(SDL2_LIBRARIES SDL2::SDL2 IMPORTED_LOCATION_NOCONFIG)|gi' "$pkgname"/neo/CMakeLists.txt
JanSimek commented 4 years ago

Shouldn't this suffice?

diff --git a/neo/CMakeLists.txt b/neo/CMakeLists.txt
index 1a36eef..74af985 100644
--- a/neo/CMakeLists.txt
+++ b/neo/CMakeLists.txt
@@ -1599,8 +1599,7 @@ else()

                if(SDL2)
                        find_package(SDL2 REQUIRED)
-                       include_directories(${SDL2_INCLUDE_DIRS})
-                       set(SDLx_LIBRARY ${SDL2_LIBRARIES})
+                       set(SDLx_LIBRARY SDL2::SDL2)
                else()
                        find_package(SDL REQUIRED)
                        include_directories(${SDL_INCLUDE_DIR})

It should both link the library and also include the header directory. Works for me on Arch using SDL 2.0.12

EDIT: I just read @noabody's linked bug report and I see the problem now. Nevertheless, perhaps this should be used anyway to teach the Debian users a lesson :smiley:

xcom169 commented 3 years ago

It's also a problem for me on Manjaro Linux.

HarrievG commented 3 years ago

@RobertBeckebans I can confirm @JanSimek solution also works for MSVC + vs2019 cmake + vcpkg (not sure about the include_dirs, im pretty sure it can be removed if VCPKG is used, but without vcpkg this could still be needed? It also does not give problems when still set)

@DanielGibson I think the SDL part could aready be pushed into master? https://github.com/HarrievG/d3wasm/commit/97fa784aa642226ce4da8abf12cb02000417fab8

KiralyCraft commented 3 years ago

I can also confirm @JanSimek 's solution works on Manjaro. Many thanks!

coldtobi commented 3 years ago

Shouldn't this suffice? (...)

This patch works for /me on Debian sid as well. I'm currently short on free time, anyone wanting to make a PR? (@KiralyCraft @HarrievG @JanSimek)

Edit: Possibly this makes minimum SDL2 version to be 2.0.12 or .14 -- I see changes in the cmake template in regards using CMake Targets. -> https://salsa.debian.org/sdl-team/libsdl2/-/blame/master/sdl2-config.cmake.in (The (Debian package) version I've used to test-compile was 2.0.14+dfsg2-3 -> https://tracker.debian.org/pkg/libsdl2)

DanielGibson commented 3 years ago

Possibly this makes minimum SDL2 version to be 2.0.12 or .14

That would be very bad as it excludes people using debian stable or Ubuntu 20.04LTS (or older).

(in dhewm3 I just went back to shipping a FindSDL2.cmake, as that seemed to work best)

coldtobi commented 3 years ago

Possibly this makes minimum SDL2 version to be 2.0.12 or .14

Note that I did not verify that. Said that, the PR I supplied originally compiles with an older SDL. (I wrote 2.0.4 in that PR, did not recheck)

That would be very bad as it excludes people using debian stable or Ubuntu 20.04LTS (or older).

(Only when they want hack on it. Otherwise I'd suggest them to use the packages from the distribution…)

(in dhewm3 I just went back to shipping a FindSDL2.cmake, as that seemed to work best)

Having a FindSDL2.cmake in the projects creates a lot of problems, especially for distributions… So it is good that SDL ships them know and projects are encouraged to drop theirs. Especially as those FindSDL2.cmake are usually severley outdated… In Debian I actually carrry a patc in dhewm3 because of a broken a FindSDL. (https://salsa.debian.org/games-team/dhewm3/-/blob/master/debian/patches/30-SDL2-CMake.patch)

DanielGibson commented 3 years ago

Only when they want hack on it.

Also if they just want to use a current version of the sourceport. I know I do - I'm happy with using a stable LTS distro and not updating everything all the time, but I want to use (more) current versions of source ports, because usually they make great improvements over the years.

So it is good that SDL ships them know and projects are encouraged to drop theirs

In theory, yes, in practice unfortunately SDL screwed it up and ships two incompatible cmake configs, and some distros use the one and others the other, and maybe their behavior even changed between SDL releases. For distro packages this might not matter, because when packaging a new $sourceport package you don't have to care about the SDL2 version of the distro's current stable release, as that new package will never land there - but as a maintainer of a sourceport it's important that it can be built on the commonly used Linux distros, including stable and LTS versions (which ship years old versions of SDL2 and other libs).

In Debian I actually carrry a patc in dhewm3 because of a broken a FindSDL

What's going wrong with the custom findsdl? I haven't tried it on debian in a while, but on ubuntu and raspbian I never had problems with it. I'd like to find a way to works best for everyone, of course, but due to the aforementioned reasons it's not easy at all. Maybe there even is a way to support both SDL2s sdl2-config.cmake and SDL2Config.cmake of all the still relevant SDL2 versions (i.e. at least back to 2.0.8), but if there is, it sure isn't straightforward.

coldtobi commented 3 years ago

What's going wrong with the custom findsdl?

smvc sumarized it very well here: https://github.com/JACoders/OpenJK/pull/1033

HarrievG commented 3 years ago

Guys. SDL is really starting to cause more problems. It will not/cannot be fixed due to the choices SDL has made in the past.

Is the idea to switch to glfw, or at least add it as an option and/or as default, the better one in the long run?

On Wed, Apr 14, 2021, 10:27 Tobias Frost @.***> wrote:

What's going wrong with the custom findsdl?

smvc sumarized it very well here: JACoders/OpenJK#1033 https://github.com/JACoders/OpenJK/pull/1033

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/469#issuecomment-819334822, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIUHNTP3THQV7RKUJOF53LTIVGYVANCNFSM4ML4FZAQ .

DanielGibson commented 3 years ago

smvc sumarized it very well here: JACoders/OpenJK#1033

That explains why using sdl2-config.cmake from libsdl2-dev is preferable (ignoring the existence of SDL2Config.cmake in other distros), but not how the supplied FindSDL2.cmake breaks the build for debian packages.

Just to be clear: Was removing FindSDL2.cmake necessary to make dhewm3/RBDoom3BFG build on debians build servers (or whatever), or was it just done because it's considered "the right thing to do"?

Is the idea to switch to glfw, or at least add it as an option and/or as default, the better one in the long run?

no.

DanielGibson commented 3 years ago

I raised this issue at https://discourse.libsdl.org/t/how-is-sdl2-supposed-to-be-used-with-cmake/31275 - hopefully someone there has an idea how to not ship your own FindSDL2.cmake and still remain compatible with common Linux distros like Ubuntu 20.04 or Arch Linux.

I also looked it up, using SDL2::SDL2 indeed only works with SDL2 2.0.12 or newer (or on distros providing SDL2Config.cmake, like Arch Linux) - even Ubuntu 20.04 ships 2.0.10 (and sdl2-config.cmake) so neither SDL2::SDL2 nor SDL2_LIBRARIES/SDL2_INCLUDES by themselves are acceptable options.

coldtobi commented 3 years ago

or SDL2_LIBRARIES/SDL2_INCLUDES by themselves are acceptable options.

SDL2_LIBRARIES/SDL2_INCLUDES works with standard Debian*packages since at least 2.0.10, probably (I say because I did not test it) even 2.0.4 (See the PR I opened at that time); so Ubuntu 20.0.4 should work, since Ubuntu is a derivative of Debian and Ubuntu generaly use the Debian's packaging -- I've verified that in this case they do not ship any Ubuntu specific patch to the packaging.

DanielGibson commented 3 years ago

Dude, did you even read what I wrote?!

There are Linux Distributions that are not based on debian.

Some of them ship SDL2Config.cmake instead of sdl2-config.cmake. SDL2Config.cmake does not support SDL2_LIBRARIES / SDL2_INCLUDES.

And, as much as I like debian and its derivatives: Source ports also want to support those other distros (and vcpkg and whatever else is used out there)

coldtobi commented 3 years ago

Dude, did you even read what I wrote?!

Pardon? My remark was only regarding Ubuntu. I did not make any other statement about any other distribution.

DanielGibson commented 3 years ago

Sorry, I think we're somehow talking past each other.

My point is: It seems like removing the custom FindSDL2.cmake in the upstream repo of source ports is bad because the alternatives break the build either on Arch Linux (and other distros/pkg managers shipping SDL2Config.cmake) or on debian-based distros that ship SDL2 < 2.0.12 (or other distros/pkg managers shipping sdl2-config.cmake, which includes Ubuntu 20.04).

So: Removing it with a patch in your debian source packages is fine, because obviously those only have to support debian-based distros, removing it here (or in the official dhewm3 repo) is not, at least unless we find a solution to support both kinds of sdl2 cmake configs (from all SDL2 versions since at least 2.0.8).

UPDATE: For clarity, the following alternatives exist (and most of them suck in one way or another):

  1. Keep/Restore FindSDL2.cmake - it works on most Linux distros and similar, as long as libSDL2.so (to link against) is in the standard library search path used by the compiler, and as long as SDL2's include directory (SDL2/) is in one of several standard directories, including /usr/include/, /usr/local/include/ or some others.
    • Sucks because it's ugly and doesn't work with non-standard paths and most probably not on Windows (unless you explicitly set the $SDL2DIR environment variable)
  2. Remove FindSDL2.cmake and use SDL2_LIBRARIES and SDL2_INCLUDES - this only works on distros/pkg managers shipping sdl2-config.cmake, like debian and derivatives, not on ones shipping SDL2Config.cmake like Arch Linux or vcpkg (and possibly others).
    • Sucks because it doesn't work on some distros
  3. Remove FindSDL2.cmake and use SDL2::SDL2 - this only works on distros shipping SDL2Config.cmake (like Arch), or ones shipping sdl2-config.cmake and SDL 2.0.12 or newer, which is not the case on several still relevant versions of Debian and Ubuntu.
    • Sucks because it doesn't work on Debian/Raspian Buster or Ubuntu up to including 20.04
  4. Remove FindSDL2.cmake and find a way to use either SDL2_LIBRARIES/SDL2_INCLUDES or SDL2::SDL2, whichever is available (or maybe even keep FindSDL2.cmake and only use it if neither alternative is available).
    • Probably sucks least, but we don't know if/how this would be done and it will most probably move complexity into the (main) CMakeLists.txt of the source port
noabody commented 3 years ago

I was wondering if the solution I posited in the initial report would work in both situations. I got the impression that ...

get_target_property(SDL2_INCLUDE_DIRS SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)
get_target_property(SDL2_LIBRARIES SDL2::SDL2 IMPORTED_LOCATION_NOCONFIG)

... would bridge the gap by providing a value from SDL2Config.cmake that would conform to the format expected by using sdl2-config.cmake.

I mean, it won't return any value in the case of the latter but I figured ...

include_directories(${SDL2_INCLUDE_DIRS})
set(SDLx_LIBRARY ${SDL2_LIBRARIES})

would take care of that.

But I really don't know much about, well, most of this stuff. I just analyze things.

DanielGibson commented 3 years ago

Ha, I had the same idea :)

I toyed around with get_target_property() a bit (on Windows with the vcpkg version of SDL2). Getting the include directories is easy enough (INTERFACE_INCLUDE_DIRECTORIES worked for me as well), but getting the equivalent of SDL2_LIBRARIES seems a lot harder.

So it seems that piecing together a proper SDL2_LIBRARIES cmake variable from SDL2::SDL2 is non-trivial, both because the target properties actually holding the relevant information vary, and because the necessary output format seems to depend on whether a GCC-like compiler or MSVC (Visual C++) is targeted.

One thing that seemed to work but is pretty dhewm3/RBDoom3BFG specific, was set(SDLx_LIBRARY SDL2::SDL2) (and, like you did, get_target_property(SDL2_INCLUDE_DIRS SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)). Then target_link_libraries(RBDoom3BFG .... ${SDLx_LIBRARY} ...) behaves just like target_link_libaries(RBDoom3BFG .... SDL2::SDL2 ...) which is valid and works. I only dislike this because SDL2::SDL2 is quite different from that string SDLx_LIBRARY normally holds, and ideally I'd like to find a generic solution that can be included in SDL2's SDL2Config.cmake, so it provides SDL2_LIBRARIES and SDL2_INCLUDE_DIRECTORIES in addition to SDL2::SDL2, to make sdl2-config.cmake and SDL2Config.cmake functionally equivalent, as far as possible - that would un-screw the situation on the SDL2 side a bit, at least starting with the next release. (One good thing is that the only distros/pkg managers I know about that ship SDL2Config.cmake instead of sdl2-config.cmake are Arch Linux + derivatives and vcpkg, which tend to provide the latest release soon after it has been released, so that fix would reach people in the foreseeable future.) And for a generic solution set(SDL2_LIBRARIES SDL2::SDL2) might not work, because maybe other peoples cmake files depend on SDL2_LIBRARIES being a normal variable holding a string, and do more fancy things with it than just passing it to target_link_libraries()...

DanielGibson commented 3 years ago

Oh, forgot, @noabody can you paste what IMPORTED_LOCATION_NOCONFIG looks like on your system?

And ideally add this code: https://stackoverflow.com/a/56738858/14633188 to your CMakeLists.txt (somewhere after find_package(SDL2 REQUIRED)) and after that add print_target_properties(SDL2::SDL2), run cmake and post the output from this?

It should print all the properties of SDL2::SDL2 (well, at least as long as there's not multiple configurations like IMPORTED_IMPLIB_DEBUG and _RELEASE, the script can't handle those, but this shouldn't happen on Linux)

On my Windows+vcpkg system it looks like this (ok, this is for dhewm3, but that shouldn't make any interesting difference):

SDL2::SDL2 AUTOGEN_ORIGIN_DEPENDS = ON
SDL2::SDL2 AUTOMOC_COMPILER_PREDEFINES = ON
SDL2::SDL2 AUTOMOC_MACRO_NAMES = Q_OBJECT;Q_GADGET;Q_NAMESPACE
SDL2::SDL2 AUTOMOC_PATH_PREFIX = ON
SDL2::SDL2 BINARY_DIR = C:/dev/dhewm3/build-vcpkg
SDL2::SDL2 BINARY_DIR = C:/dev/dhewm3/build-vcpkg
SDL2::SDL2 BUILD_WITH_INSTALL_RPATH = OFF
SDL2::SDL2 IMPORTED = TRUE
SDL2::SDL2 IMPORTED_CONFIGURATIONS = DEBUG;RELEASE
SDL2::SDL2 IMPORTED_GLOBAL = FALSE
SDL2::SDL2 INSTALL_RPATH = 
SDL2::SDL2 INSTALL_RPATH_USE_LINK_PATH = OFF
SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES = D:/dev/vcpkg/installed/x86-windows/include;D:/dev/vcpkg/installed/x86-windows/include/SDL2
SDL2::SDL2 NAME = SDL2::SDL2
SDL2::SDL2 POSITION_INDEPENDENT_CODE = True
SDL2::SDL2 SKIP_BUILD_RPATH = OFF
SDL2::SDL2 SOURCE_DIR = C:/dev/dhewm3/neo
SDL2::SDL2 SOURCE_DIR = C:/dev/dhewm3/neo
SDL2::SDL2 TYPE = SHARED_LIBRARY
SDL2::SDL2 TYPE = SHARED_LIBRARY
SDL2::SDL2 UNITY_BUILD_BATCH_SIZE = 8

and the following I checked by "manually" calling get_target_property():

IMPORTED_IMPLIB = NOTFOUND
IMPORTED_IMPLIB_NOCONFIG = NOTFOUND
IMPORTED_IMPLIB_DEBUG = D:/dev/vcpkg/installed/x86-windows/debug/lib/SDL2d.lib
IMPORTED_IMPLIB_RELEASE = D:/dev/vcpkg/installed/x86-windows/lib/SDL2.lib
noabody commented 3 years ago

This is the output:

SDL2::SDL2 BINARY_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2 IMPORTED = TRUE
SDL2::SDL2 IMPORTED_CONFIGURATIONS = NOCONFIG
SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES = /usr/include;/usr/include/SDL2
SDL2::SDL2 LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 LOCATION_ = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 MACOSX_PACKAGE_LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 NAME = SDL2::SDL2
SDL2::SDL2 POSITION_INDEPENDENT_CODE = True
SDL2::SDL2 SOURCE_DIR = /rbdoom3bfg/src/rbdoom3bfg/neo
SDL2::SDL2 TYPE = SHARED_LIBRARY
SDL2::SDL2 VS_DEPLOYMENT_LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0

Hmm... at some point I altered my changes to neo/CMakeLists.txt

            include_directories(${SDL2_INCLUDE_DIRS})
            set(SDLx_LIBRARY ${SDL2_LIBRARIES})
            include_directories(SDL2::SDL2)
            set(SDLx_LIBRARY SDL2::SDL2)

Not real sure why. The other version worked too. I guess I figured the old style would work the old way, and the new style wouldn't work on the old so it shouldn't change the return value? Or maybe I wasn't concerned about it. Sorry, I'm getting a bit more forgetful these days.

EDIT: Those last changes were based on the Arch packaging sdl2-cmake.patch

DanielGibson commented 3 years ago

Thanks! I enhanced that function a bit so it also shows entries that end with <CONFIG>, can you run it again with this one? https://gist.github.com/DanielGibson/ca02b1692499ce4911f7884dc0a67bbf#file-cmakelists-txt-L13-L59

RobertBeckebans commented 3 years ago

Does this mean we have a better solution now?

DanielGibson commented 3 years ago

Not yet, but I'm optimistic.

noabody commented 3 years ago 
SDL2::SDL2 BINARY_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2 BINARY_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2 IMPORTED = TRUE
SDL2::SDL2 IMPORTED_CONFIGURATIONS = NOCONFIG
SDL2::SDL2 IMPORTED_GLOBAL = FALSE
SDL2::SDL2 IMPORTED_LOCATION_NOCONFIG = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 IMPORTED_SONAME_NOCONFIG = libSDL2-2.0.so.0
SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES = /usr/include;/usr/include/SDL2
SDL2::SDL2 LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 LOCATION_NOCONFIG = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 MACOSX_PACKAGE_LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2 NAME = SDL2::SDL2
SDL2::SDL2 POSITION_INDEPENDENT_CODE = True
SDL2::SDL2 SOURCE_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2 SOURCE_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2 TYPE = SHARED_LIBRARY
SDL2::SDL2 TYPE = SHARED_LIBRARY
SDL2::SDL2 VS_DEPLOYMENT_LOCATION = /usr/lib/libSDL2-2.0.so.0.14.0
SDL2::SDL2main BINARY_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2main BINARY_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2main IMPORTED = TRUE
SDL2::SDL2main IMPORTED_CONFIGURATIONS = NOCONFIG
SDL2::SDL2main IMPORTED_GLOBAL = FALSE
SDL2::SDL2main IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG = C
SDL2::SDL2main IMPORTED_LOCATION_NOCONFIG = /usr/lib/libSDL2main.a
SDL2::SDL2main INTERFACE_INCLUDE_DIRECTORIES = /usr/include;/usr/include/SDL2
SDL2::SDL2main LOCATION = /usr/lib/libSDL2main.a
SDL2::SDL2main LOCATION = /usr/lib/libSDL2main.a
SDL2::SDL2main LOCATION_NOCONFIG = /usr/lib/libSDL2main.a
SDL2::SDL2main MACOSX_PACKAGE_LOCATION = /usr/lib/libSDL2main.a
SDL2::SDL2main NAME = SDL2::SDL2main
SDL2::SDL2main SOURCE_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2main SOURCE_DIR = /rbdoom3bfg/src/rbdoom3bfg/build
SDL2::SDL2main TYPE = STATIC_LIBRARY
SDL2::SDL2main TYPE = STATIC_LIBRARY
SDL2::SDL2main VS_DEPLOYMENT_LOCATION = /usr/lib/libSDL2main.a
DanielGibson commented 3 years ago

Thanks!

tapir commented 2 years ago

Not sure if it adds something to the discussion but this is also broken in vanilla Arch install.

RobertBeckebans commented 2 years ago

Would https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/546/commits/f38cb29cf60b480f9a673f881034dfc250117747 break the build on Debian stable? I'm tending to accept to the Arch Linux fix.

coldtobi commented 2 years ago

Would f38cb29 break the build on Debian stable? I'm tending to accept to the Arch Linux fix.

Test-compiled f38cb29: No further tests done beside compiling,

-- Configuring done
CMake Error at CMakeLists.txt:1786 (add_executable):
  Target "rbdoom3bfg" links to target "SDL2::SDL2" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
DanielGibson commented 2 years ago

I'd suggest using something like

if(SDL2_LIBRARIES)
    include_directories(${SDL2_INCLUDE_DIRS})
    set(SDLx_LIBRARY ${SDL2_LIBRARIES})
else()
    set(SDLx_LIBRARY SDL2::SDL2)
endif()

or you just restore FindSDL2.cmake, it's not like it actually broke anything

RobertBeckebans commented 1 year ago

Is this still a thing?

xcom169 commented 1 year ago

Not anymore

On Sat, 25 Feb 2023, 12:45 Robert Beckebans, @.***> wrote:

Is this still a thing?

— Reply to this email directly, view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/469#issuecomment-1445062956, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH2G2UR2OB7YJBU2PPCJBLWZHWE3ANCNFSM4ML4FZAQ . You are receiving this because you commented.Message ID: @.***>

RobertBeckebans commented 1 year ago

Thank you then I'm closing this.