[patch] Improvement to Makefile for mac systems

[ArthurDenture]

I've attached a patch that tweaks the Makefile to work better on stock Mac OS X systems:
- use /System/Library/Frameworks/SDL.framework as the default SDL location instead of /System/Libraries/Frameworks/SDL
- don't bother checking sdl-config on a mac, since the mac distribution of libsdl doesn't come with that utility.

The patch also includes an update to the readme.txt mentioning that you also need SDLMain.h and SDLMain.m to compile simutrans on a mac.

[TurfIt]

Might want to try again with the patch... contains nothing but the filename.

[ArthurDenture]

Oops, sorry about that, reattaching.

There's one more fix in this version, since I noticed one more bug with the existing mac makefile. The CoreAudio sound library, sound/core-audio_sound.mm, isn't able to load sound files (and then, not checking for their nonexistence, crashes when trying to play a sound). So I've changed the makefile to use sound/sdl_sound.cc on all OSes when the sdl backend is used.

I've also got one more patch to share: instead of having separate SDL and SDL_mixer backends, have a separate flag USE_SDL_MIXER. The point of this was to try out SDL_mixer on mac without having to duplicate the e.g. the logic that sets SDL_CFLAGS and SDL_LDFLAGS. It ends up that there's not really much advantage in using SDL_mixer on mac; it appears on Linux the advantage it gives you is midi support, but on mac, midi is already supported via CoreAudio. So this patch ends up not being much of a win except perhaps some cleaner logic. I'm sharing it anyway just in case you think it's an improvement.

[wernieman]

I don't linke that sdl.config is not use ...

on the nightl-compiler-system I use it for some "hacks" to get the mac-cross-compiler to work.
Can you check if the file i exist o not? when exist then use ....

[ArthurDenture]

Sorry for the lag - I tend to only get around to personal programming stuff on weekends.

Anyhow, cross-compilation is not the only use case I overlooked. There are also users on a mac who install the Unix-style sdl library from Fink, MacPorts, or Homebrew, rather than installing it as a framework. So I've changed the makefile to try sdl-config first and only override SDL_CFLAGS if it remains empty after calling sdl-config (as will happen if sdl-config does not exist).

For the framework style of library distribution, the ideal include path is apparently <SDL/SDL.h>, i.e. including the framework name. That lets us drop -I for macs altogether and just search the standard include paths. That has the advantage of allowing SDL.framework to be in any standard location instead of only checking /System/Library (or manually specifying every standard path in the makefile).

My initial try was to use the framework-style include path if __APPLE__ is defined. But that would be wrong for users with the Unix-style sdl library, so instead I've added -DUSE_FRAMEWORK_SDL to control that. It's only set if sdl-config does not exist.

Managing these patches was getting unwieldy :-), so I've pushed my changes to Github, at https://github.com/artdent/simutrans/tree/mac.

I've tested this branch with SDL.framework, with libsdl from Homebrew, and on Ubuntu. I have no idea what your cross-compilation setup is, but hopefully this version will work for you.

[prissi]

Aparently the framework location changed several times. On my ancient PowerMac emulator it was enforced in said location.

(Usually to compile I just set the parameter in the config.default file, i.e. to compule without sdl.config I could just add -I/system/... to the include line where I define LDFLAGS and CCFLAGS.)

[ArthurDenture]

Yeah, it's always possible to hack your way through it :-), and doing so is not hard once you understand the sorta-Unix-but-different world of Mac development. The point of this change is to make it easier for new users to contribute by getting rid of those initial makefile tweaks.

[prissi]

Could you provide a diff? GIT does not work together with my customized environment, as it is one extremly ugly hack on windows.

[ArthurDenture]

Sure, attached.

[ArthurDenture]

Ping? Wernieman, does this patch work for you for cross-compilation?

[wernieman]

I must recheck it next week ....

[Dwachs]

Any news?

[wernieman]

It Looks good, but ...

in the Make-File are absolute Paths:
at example:
+    SDL_CFLAGS  := -I/System/Library/Frameworks/SDL.framework/Headers -Dmain=SDL_main
+    SDL_LDFLAGS := -framework SDL -framework Cocoa -I/System/Library/Frameworks/SDL.framework/Headers SDLMain.m

Could we use for the Path (/System/Library) a Variable, that could set in the config.default?

[Ashley]

We could just put both locations in:

Code Select Expand

      SDL_CFLAGS  := -I/Library/Frameworks/SDL.framework/Headers/ -I/System/Libraries/Frameworks/SDL/Headers -Dmain=SDL_main
      SDL_LDFLAGS := -framework SDL -framework Cocoa -I/Library/Frameworks/SDL.framework/Headers/ -I/System/Libraries/Frameworks/SDL/Headers SDLMain.m


Will work in either case, since it'll ignore the location which doesn't exist.

[TurfIt]

3 years later, and it still doesn't compile on a Mac out of the box. I think we need to fix that...

The USE_FRAMEWORK_SDL gets around the hardcoded paths, but clutters up the source files, especially once extended for SDL2 as well. Unless we just drop Mac SDL1 support since it's now terrible.

core-audio_sound and _midi are working for me, and far better than the native Windows stuff too since Vista broke them. The compiler does complain about the functions called all being deprecated though. Is there still a need to drop using them?


After bashing my head against the wall for 8+ hours trying to get a working Mac compile - proposed patch attached.
Added 'mac32' OSTYPE to force creation of a 32bit binary - still much better performance than 64. Is there a better way than adding ostypes to the makefile to do this?
Using /Library/Frameworks/SDL2.framework as the location when sdl2_config isn't defined. This is where the SDL2 instructions say to put it. This is where I put it. If someone puts it elsewhere, onus on them to know what they're doing IMHO. If using a unix style install, then sdl2-config should be there...
Removed -Os -fast. Don't see why Mac should have different optimization flags than the others.
Enabled TCP_NODELAY. Not sure why this was specifically excluded for __APPLE__. It is required for network play. Period.
Excluded defining _XOPEN_SOURCE since the Mac pthread.h file excludes defining PTHREAD_RECURSIVE_MUTEX_INITIALIZER if _XOPEN_SOURCE is defined. Bizarre. And Mac has no barrier support anyways.

I am very much a Mac noob, so any input from more experienced users would be appreciated.

[ArthurDenture]

I don't know if I'll have time to look at your patch (busy with work), but here a few very quick thoughts:

- I highly recommend using Homebrew to get the Unix-style libsdl2 package. It's nicely maintained, documented, and in general much easier than the old world of using fink or macports to get unix packages. (Of course, it's still a worthy goal to fix compilation with framework-based SDL.)

- It looks like the deprecations in core-audio are new in 10.9. https://developer.apple.com/library/mac/technotes/tn2300/_index.html describes the replacement. I imagine there's some time before the QTKit API actually goes away...

- My instinctive reaction is against adding yet another OSTYPE target. If the goal is to make it easier to compile from source, then having to guess correct values for OSTYPE and BACKEND is already intimidating without also having to decide between 32-bit and 64-bit.

[Ters]

Removed -Os -fast.

That certainly might explain some poor performance.

[TurfIt]

- I highly recommend using Homebrew to get the Unix-style libsdl2 package. It's nicely maintained, documented, and in general much easier than the old world of using fink or macports to get unix packages. (Of course, it's still a worthy goal to fix compilation with framework-based SDL.)

From what I can see, there's been many issues with 'dyld: Library not loaded:' for /sw/lib/libSDL...,  @executable_path/../Frameworks/SDL.framework...,  /usr/local/lib/libSDL..., /Library/Frameworks/SDL.framework..., /System/Library/Frameworks/SDL.framework..., /Libraries/..., /System/Libraries/..., and on and on and on.

I guess these paths end up hardcoded in the executable or something, but sure is a nuisance. I presume the Library vs Libraries was some change made in OSX? Certainly a newly installed Mavericks has only Library. /System/Library vs /Library maybe a personal preference? And /usr/..., /sw/... presumably from the various UNIXey installs. What's a 'normal' Mac user most likely to use? The SDL download from the official site has only a single .dmg file for both runtime and development. Inside is a readme.txt stating to put the framework into /Library. I think that's the only thing Simutrans should officially support.

- My instinctive reaction is against adding yet another OSTYPE target. If the goal is to make it easier to compile from source, then having to guess correct values for OSTYPE and BACKEND is already intimidating without also having to decide between 32-bit and 64-bit.

The other option is another variable to control 32 vs 64... e.g. FORCE32BIT = 1 or something. Not sure what's worse...
config.template could have some comments added to describe which backend(s) should go with which OSs.

That certainly might explain some poor performance.

Their presence? or removal? Every other platform uses DEBUG, OPTIMISE, and PROFILE to control the compiler flags. Setting only OPTIMISE gives the compiler -O3 which seems just fine for Macs too.

[Ters]

Their presence? or removal? Every other platform uses DEBUG, OPTIMISE, and PROFILE to control the compiler flags. Setting only OPTIMISE gives the compiler -O3 which seems just fine for Macs too.

-Os means pretty much exactly the opposite of -O3 (but not quite). Where -O3 is willing to generate more machine code in order to increase performance, -Os will sacrifice performance for the smallest possible machine code. I see no reason for Simutrans to use -Os. The size of all the data files will likely dwarf any savings in executable size.

[MCollett]

/System/Library vs /Library maybe a personal preference? And /usr/..., /sw/... presumably from the various UNIXey installs. What's a 'normal' Mac user most likely to use?

/System/Library is supposed to be only for system (i.e. Apple-installed) stuff.  In theory, any user or third-party things in here could get tromped on by a future system update.  Not likely to happen in practice, but why take the risk?

/Library (more specifically, /Library/Frameworks) should be the default location for user or third-party libraries. 

There is also /Users/username/Library; this is mainly for user preferences and such, but it is perfectly possible and legal to put a library here if you want to restrict access to it to a single user.

Best wishes,
Matthew