How to compile Wesnoth on Mac OS X

[alexcurylo]

Anyway, sorry about that, and here's those files. Thanks for pointing it out!

No, thank you! That dePythonizing sorts out an apparently functional build nicely with rev 32514 as advertised, and with the latest rev 33127 once I delete ai/python.cpp and add gui/dialogs/addon_list.cpp, so everything appears good.

(There was also some strange confusion with the Carbon.framework reference, but readding it relative to current SDK sorted that ... you might want to check and make sure it's actually linking to what you think it is on your machine.)

My actual interest in this is to take a look at what kind of effort is involved in sorting out some kind of an iPhone version. You made any attempt at linking this against the iPhone SDK? Or know anyone else already working on that?

[ancestral]

Anyway, sorry about that, and here's those files. Thanks for pointing it out!

My actual interest in this is to take a look at what kind of effort is involved in sorting out some kind of an iPhone version. You made any attempt at linking this against the iPhone SDK? Or know anyone else already working on that?

You'll need to find SDL 1.3. (http://www.libsdl.org/tmp/SDL-1.3.zip) It does have iPhoneOS support. Read the readme files, however, as there are some limitations.

Personally, I'm curious if building SDL 1.3 with Wesnoth will finally enable horizontal scrolling, which, I read, was a feature initially planned in a late version of 1.2 and was then tabled for inclusion 1.3. One of the developers of SDL (who is also a Lead Dev at Blizzard, btw) said it should work with SDL 1.3 (assuming you've coded it correctly). Unsure if there's code that may need to be revised in the Wesnoth project, but I think the calls for reading the horizontal input are actually there, so who knows.

[anakayub]

Small modification to penguin's mac compile kit: It allows opening the saves folder in the Finder via the menu bar, useful for those who like to watch others' replays or upload their own without having to navigate to find it.

[penguin]

Ah, good idea. Though, 1.6 data will go in a new folder, so this won't work for 1.6. But I'll see about adding it in, and I should make a new compile kit for 1.6 once it's announced too.

I'm kinda... very busy, tired, and disoriented right now though. I'm on a trip to BC (from Ontario).

[anakayub]

It's basically for my personal use, but can be shared for others' use. I'm planning to add some other useful functions such as opening the Editor Maps folder and probably the "addons" folders.

What I suggest you do is make the data folder the same for a series (development & stable of same cycle) altogether, e.g. 1.5-1.6 into a Wesnoth_1.6 folder, and 1.7-1.8 into a Wesnoth_1.8 folder, etc. Besides, in theory the "rc" series are in general finished, and so they should be able to use the same data folder (for add-ons).

But it's a minor point, so it's up to you.

[ivanovic]

It's basically for my personal use, but can be shared for others' use. I'm planning to add some other useful functions such as opening the Editor Maps folder and probably the "addons" folders.

What I suggest you do is make the data folder the same for a series (development & stable of same cycle) altogether, e.g. 1.5-1.6 into a Wesnoth_1.6 folder, and 1.7-1.8 into a Wesnoth_1.8 folder, etc. Besides, in theory the "rc" series are in general finished, and so they should be able to use the same data folder (for add-ons).

Bad idea, really bad idea. Over the turns of the dev line we often break compatibility one way or the other. This can even happen in RC time. And users trusting on data in the dir to "just work" would easily feel screwed if the stuff they have in their dir does not work at all. So it is better to start a "new prefs dir" when the new series is *really* out and compatibility will be kept.

Yes, for all dev versions it is fine to have them in a dir and if things break, but the move to the "stable line" should not have you end with data that won't work!

[anakayub]

I stand corrected then.

EDIT: This allows savegames, app data, and editor maps. That's all my limited programming can let me (and already overkill for my use of Wesnoth).

[SnippyHolloW]

Hi, I'm new here. I have (many) problems compiling wesnoth for Mac OS 10.5.6 (Leopard) on a MacBook Pro Core 2 Duo 2.2ghz ! I tried many things : XCode and CMake, different libs (from MacPorts and from latest Mac_Compile_Stuff), following the wiki, not following the wiki, modifying the sources, not modifying the sources, from svn trunk, from .tar.gz ... I have something like 4gigs of sources (2 svn, 2 inflated tar.gz) and the best I can get are LD errors with XCode (and with CMake something like if my boost library was linked even if I specify the dylib and Headers from Mac_Compile_Stuff and it's a boring "no file" for a header that really exists at the given path . . . I precised Leopard because I have to compile it with the 10.4 SDK as things like 'GetCurrentScrap' from HIToolbox.framework are deprecated in 10.5. Scons won't even find libX11 and libintl though my macport library are all clean and used in other projects ...

I think that my best setup is XCode with 10.4 SDK and Mac_Compile_Stuff libraries (mainly), I can get until the linking stage with only 6 warnings warning (and one about "passing argument 2 incompatible pointer type" for NSApplicationMain (argc, argv);) but then it crashed during linking with (full crash log is attached):

Code: Select all

ld: duplicate symbol mp::connect::side::allow_player() constin /Users/snippy/Desktop/old_svn/Mac_Compile_Stuff/build/Wesnoth.build/Debug/Wesnoth.build/Objects-normal/i386/multiplayer_connect-A9A0436D.o and /Users/snippy/Desktop/old_svn/Mac_Compile_Stuff/build/Wesnoth.build/Debug/Wesnoth.build/Objects-normal/i386/multiplayer_connect-A9A0436D.o

I had to modify a lot of sourcefiles that had wrong header paths (but I don't think that I did wrong things : it was obvious like for example :
gui/widgets/foo.hpp contained #include "gui/dialogs/bar.hpp" and I just modified gui/widgets/foo.hpp to #include "../dialogs/bar.hpp", sed was my friend as always.

I though it was "not hard" (CompilingWesnoth - how to compile Battle for Wesnoth (it's not hard) ) to compile Wesnoth but so there has to be something wrong with my setup ! I hope that somebody there will have a clue. I spent like one day about it ...

[alexcurylo]

Hi, I'm new here. I have (many) problems compiling wesnoth for Mac OS 10.5.6 (Leopard)

Looks like you might be using the "Debug" configuration in the Xcode project? Yeah, it's kinda a mess, at least it was a month ago when I got it going (see above). Try "Release" configuration instead, then you should have virtually no trouble.

[SnippyHolloW]

Ok I understand, Debug isn't up to date at all ... I'm compiling with Release right now, I keep you updated.

Edit: Also an error of linking (debug), not the same method but the same file ...

Code: Select all

ld: duplicate symbol mp::connect::side::hide_ai_algorithm_combo(bool)in /Users/snippy/Desktop/old_svn/Mac_Compile_Stuff/build/Wesnoth.build/Release/Wesnoth.build/Objects-normal/ppc/multiplayer_connect-A9A0436D.o and /Users/snippy/Desktop/old_svn/Mac_Compile_Stuff/build/Wesnoth.build/Release/Wesnoth.build/Objects-normal/ppc/multiplayer_connect-A9A0436D.o
collect2: ld returned 1 exit status

I'm trying clean->build and thinking about what it could be !

Edit2: Same with clean->build ...

[anakayub]

You might be compiling duplicate source files (probably multiplayer_connect.cpp). The error message should be able to tell you what's wrong. You can safely ignore warnings.

You should be able to compile without modifying the source files or the compile kit for beginners. Use the compile kit provided by penguin in this thread, as it cleaned up the compile kit used by me previously. Use release, and then it'll be easier for others to help you.

[SnippyHolloW]

You might be compiling duplicate source files (probably multiplayer_connect.cpp).

I attach one screen shot, I don't see duplicates.

The error message should be able to tell you what's wrong.

That's where I'm lost ... The error message is above.

You can safely ignore warnings.

I'm already good at that

You should be able to compile without modifying the source files or the compile kit for beginners. Use the compile kit provided by penguin in this thread, as it cleaned up the compile kit used by me previously. Use release, and then it'll be easier for others to help you.

I'll checkout another time and just put the latest Mac_Compile_Stuff into and compile in Release (with SDL.h and Boost linked) ... That's what I did for Debug and I think that I did nothing wrong, but that's sure I did too many things !

[anakayub]

Hm, it's pretty difficult to help you from afar, but try compiling for 1 architecture first; I think from your screenshot you're making a UB. That way you'll get frustrated in only half the time.

But the error message does say that you're compiling duplicate symbols, so that's where you should look for. Take a break and continue later.

[alexcurylo]

I'll checkout another time and just put the latest Mac_Compile_Stuff into and compile in Release (with SDL.h and Boost linked) ... That's what I did for Debug and I think that I did nothing wrong, but that's sure I did too many things !

Well, I checked out the latest (34212) and here's my Mac compile folder,

http:files.me.com/alexcurylo/bvpz7f

so if you drop it into a fresh checkout the Release target ought to work fine like it just did for me. All I did since the conversations above was add a few new files from the main tree and to the Mac lib folder a recentish (5.1.2, seems to be good enough) version of Lua.framework since apparently Lua support has been added in the last month, which is kinda nifty.

Oh, and if you have a PPC machine you'll want to turn compiling for that back on in the target settings. I turned it off since my point with this is to look at an iPhone port ... in that copious free time I haven't found any of so far

[SnippyHolloW]

http:files.me.com/alexcurylo/bvpz7f

Thanks, it works fine.

All I did since the conversations above was add a few new files from the main tree and to the Mac lib folder a recentish (5.1.2, seems to be good enough) version of Lua.framework since apparently Lua support has been added in the last month, which is kinda nifty.

I did make it work also yesterday (I'm in Japan, I mean 7 hours ago) by adding the scripting/{lua_files} and the other missing files (sound_something) in the previous .xcodeproj, I then had linking problems with Lua that was strange since I have a full working LUA install working thanks to macports so I did compile LUA and a dylib of LUA by hand ... Btw, where did you find this last LUA framework ? there ?