"make" system not robust for different Windows and MacOS Compilation

[WingofaGriffin]

When trying to automate compilations for Supermodel, I've run into issues specifically with compilers not being able to find the installation of the headers for SDL2 and SDL2_net in Windows and MacOS. For some reason, Linux is fine, but I have only tested one distro.

Taking a look at the makefiles, it seems that they are looking for the headers in one single specific location, which does not always tend to be where they are installed. For example, when installing SDL2 via homebrew on MacOS, it does not install SDL.h to /Library/Frameworks as expected as seen here: https://stackoverflow.com/questions/70641086/how-can-i-set-up-sdl-for-m1-mac-to-use-with-c

However, even when hard coding the makefile to use this location, it throws errors:

ld: warning: directory not found for option '-F/opt/homebrew/Cellar/sdl2/2.30.0/include/SDL2'
ld: warning: option -s is obsolete and being ignored
ld: framework not found SDL2

Windows throws similar errors:

In file included from Src/OSD/SDL/Main.cpp:78:
Src/OSD/Windows/DirectInputSystem.h:36:10: fatal error: SDL.h: No such file or directory
   36 | #include <SDL.h>

From my limited C developer experience, it seems that the current Makefile system is not robust enough to handle these dependency installations when not installed exactly as expected. This would be less of an issue if all binaries were provided pre-packaged, but this is not currently the case.

I suggest moving over to cmake or meson (possibly even using ninja or some other build system) as more robust multiplatform C compilers to help avoid these issues as well. Many other open source tools use SDL2 and avoid these issues, so I am curious where the problem lay.

[SNKWiz]

In OSX makefile the SDL Framewwork standard path must be added to rpath in PLATFORM_LDFLAGS.

PLATFORM_LDFLAGS = $(SDL_LIBS) -lz -lm -lstdc++ -F/Library/Frameworks/ -Wl,-rpath,@executable_path/../Frameworks -Wl,-rpath,~/Library/Frameworks -Wl,-rpath,/Library/Frameworks

[trzy]

The UNIX Makefile has this:

SDL2_CFLAGS = `sdl2-config --cflags`
SDL2_LIBS = `sdl2-config --libs`

Have you tried this solution for macOS? Would it possibly resolve this issue? Here's what happens when I run it on my system:

(base) Barts-MBP:argpt-for-ios bart$ sdl2-config --libs
-L/opt/homebrew/lib -lSDL2
(base) Barts-MBP:argpt-for-ios bart$ sdl2-config --cflags
-I/opt/homebrew/include/SDL2 -D_THREAD_SAFE
(base) Barts-MBP:argpt-for-ios bart$ 

[trzy]

SDL2 and zlib are really our only external dependencies. I would strongly prefer to make this work with a clever Makefile before going nuclear (cmake, ninja, etc.). One advantage of macOS and Linux is that you have a guarantee of a more functional shell to work with than on Windows, where I typically build using Command Prompt (but use bash on Windows for the build bot that uploads builds to supermodel3.com).

I feel like it should be quite possible to work with this. If I understand correctly, the issue is that the SDL2 path differs depending on whether it was installed with brew or manually. The sdl2-config script is provided by SDL2 to help here. If that doesn't work, don't we essentially have two possibilities, making it potentially possible to write a shell or even a native Makefile command to test for one or the other?

[SNKWiz]

No nuclear things needed.. This has nothing to do with homebrew. On a Mac SDL/SDL2 can be either installed manually or with brew. Independent of this, it's about where frameworks/libraries are stored on a Mac. The correct place is either "~/Library/Frameworks" or "/Library/Frameworks". So simply add these two path to the rpath variable in PLATFORM_LDFLAGS in the OSX makefile.

Once compiled with this change, supermodel will work for every Mac user.

[h0tw1r3]

No nuclear things needed.. This has nothing to do with homebrew. On a Mac SDL/SDL2 can be either installed manually or with brew. Independent of this, it's about where frameworks/libraries are stored on a Mac. The correct place is either "~/Library/Frameworks" or "/Library/Frameworks". So simply add these two path to the rpath variable in PLATFORM_LDFLAGS in the OSX makefile.

Once compiled with this change, supermodel will work for every Mac user.

Doesn't it have a little bit to do with homebrew? Frameworks are linked differently than standard shared libraries.

PLATFORM_LDFLAGS = $(SDL_LIBS) -lz -lm -lstdc++ -F/Library/Frameworks/ -Wl,-rpath,@executable_path/../Frameworks -Wl,-rpath,~/Library/Frameworks -Wl,-rpath,/Library/Frameworks

One word of caution for anyone seeing this, the home directory (tilde) in ~/Library/Frameworks is expanded by the shell before it is added to the rpath list in the binary. Also, typically you'll need to add the requisite -F flag for each path.

[SNKWiz]

Hi Bart I can confirm that your recent changes regarding the macOS build work. Not my favorite approach, but it does the job and for inexperienced users it's perfect because the SDL framework comes with the build. Thanks for your great work and regards Markus

…

Am 6/3/24 um 01:16 schrieb Bart Trzynadlowski ***@***.***>: SDL2 and zlib are really our only external dependencies. I would strongly prefer to make this work with a clever Makefile. One advantage of macOS and Linux is that you have a guarantee of a more functional shell to work with than on Windows, where I typically build using Command Prompt (but use bash on Windows for the build bot that uploads builds to supermodel3.com). I feel like it should be quite possible to work with this. If I understand correctly, the issue is that the SDL2 path differs depending on whether it was installed with brew or manually. The sdl2-config script is provided by SDL2 to help here. If that doesn't work, don't we essentially have two possibilities, making it potentially possible to write a shell or even a native Makefile command to test for one or the other? — Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFLWWTM5MUO4LW2AYFN7CGLYWZN47AVCNFSM6AAAAABECIZLCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZHA2TCNZUGI>. You are receiving this because you commented.