Opened 7 years ago
Closed 5 years ago
#55 closed defect (fixed)
SDL2 macOS
Reported by: | Owned by: | PulkoMandy | |
---|---|---|---|
Priority: | major | Milestone: | 2.6 |
Component: | GrafX2 | Version: | 2.5 |
Keywords: | patch sdl2 | Cc: |
Description
Hi,
I've been reworking the Makefile bits for OSX, since it was quite messed up.
I'll try to sum up all changes:
- SYSPNG=1 (ON by default) to build using macOS's libpng, otherwise, it is searched via pkg-config
- NOFW=0 to build using macOS frameworks and bundle them properly
- When using bundles, the executable will now look for it's bundled ones instead of /Library/Frameworks
- Fixed bug on macOS where building with TTF support would crash the app
- Framework resigning, needed to make the app load
- MAJOR CHANGE: SDL_PREFIX defined in source files when incuding SDL headers. For frameworks, it needs SDL2/<header>, but for classic unix-like header search we need <header>. I am aware currently prefixed headers were used, and it could break on other OSs and setups. So far, the standard way of including SDL2 seems to be non-prefixed. Just use SDL_PREFIX if you need to use prefixed headers.
- make clean will now clean Grafx2.app as well
- Fixed make uninstall on macOS. Note that install will work but the binary will not be able to properly find resources and will not load properly. Currently, there is only support for bundled Grafx2.
- MAJOR CHANGE: Default skin changed from DPaint to Modern. This is a temporary change until skin related work is stable.
- Removed SDLMain.m, which was used for SDL1.2
- Updated COMPILING doc to reflect changes
- Using $(MKDIR), $(RMDIR), $(CP)...
- Updated sources to avoid including SDL_syswm for GP2X and other systems where it is not available
I believe that's all.
Attachments (1)
Change History (12)
by , 7 years ago
Attachment: | gfx2_sdl2_osx.diff added |
---|
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Are you sure about the need for un-prefixed SDL.h? That was the case for SDL1.2, but it seems to have changed for SDL2. At least the first tutorial I find on libSDL website uses prefixed paths:
http://www.willusher.io/sdl2%20tutorials/2013/08/15/lesson-0-linux-command-line
This makes more sense and avoids some confusion when you mix SDL1 and SDL2 in the same project (happened accidentally for us: sdl_ttf 1.2 + SDL2 don't play well).
I would go with prefixed path everywhere.
You can ignore the GP2X/Caanoo stuff, these platforms don't have an SDL2 port as far as I know. We will probably keep the SDL1 version of GrafX2 for them for some time.
comment:3 by , 7 years ago
On prefixing, so far systems I've tested SDL2 expect unprefixed headers (except for macOS w FW). I've checked on macOS with brewed sdl2 (pkg-config) and Raspbian, via aptitude (SDL2 2.0.0) and via compiled sources (SDL2 2.0.5).
Prefixes headers seems "safe" to me, but I'd rather go with what is expected by default and give the chance to modify it (i.e. SDL_PREFIX)?
On GP2X stuff, I imagined :) just saw it was conditioned somewhere and kept the consistency all along.
comment:4 by , 5 years ago
Milestone: | 2.5 → 2.6 |
---|
comment:5 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 5 years ago
Have you been able to test the new sources that are compatible with both SDL and SDL2 ? just
$ API=sdl2 make
to compile.
However I see that most part of your patch are still relevant.
comment:7 by , 5 years ago
Tried 995f918
:
API=sdl2 make
works fine using brewed libs (lua, sdl2 and sdl2_image).
However, it fails due to showimage
code still using legacy SDL. I did some adjustments to its Makefile and avoided deprecated constructions (hadn't got time to port it, so it basically does nothing atm) and it compiles.
The app opens properly. Nothing wrong so far.
comment:10 by , 5 years ago
I fixed the showimage thing :)
https://gitlab.com/GrafX2/grafX2/commit/c8d2851d63e4f92f134b78cebd6c44998a019708
comment:11 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm closing, as I think most of this is not relevant anymore.
MacOS builds now statically link the non-system libraries so we don't have to mess up with Frameworks anymore.
Missed this one: