precompiled mac version done

[JuliusColtranePille]

>Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

thanks. sorry but i've now fixed the javascript slowness bug and updated the file again runs fine now

i (we) owe you one. big time.

[Ykkrosh]

Uploaded again (650f5ea5f0d80b27c43547cecc10b8e7). (Well, downloaded rather than uploaded, but whatever )

[JuliusColtranePille]

>Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

thanks. sorry but i've now fixed the javascript slowness bug and updated the file again runs fine now

somehow the freezing still happens...

am i the only one?

EDIT:

works totally fine now...

Edited September 19, 2011 by JuliusColtranePille

[mpsii]

Thanks for the files. Testing the pre-built binary now.

[JuliusColtranePille]

is there a possibility to get atlas running somehow?

outside the game or elsewhere?

thx,

regards

[historic_bruno]

is there a possibility to get atlas running somehow?

outside the game or elsewhere?

thx,

regards

As of r10300, this is possible

Note: you'll need the wxWidgets-devel (2.9.x) library also known as wxOSX/Cocoa, because a 64-bit build is only possible with Cocoa (the stable 2.8 version of wxMac used Carbon instead). cc_julian will need to create the Xcode projects for Atlas, if not already, and bundle that dependency Otherwise just use the usual build instructions for OS X (update-workspaces, etc).

[cc_julian]

i am a bit short of time currently. if someone provides me with a pre-built deployable binary of wxWidgets devel 64 bit (.a or .dylib or .framework) i will give it a try tomorrow, else i will look at it next week.

check dependencies of libraries with "otool -L"

[JuliusColtranePille]

i am a bit short of time currently. if someone provides me with a pre-built deployable binary of wxWidgets devel 64 bit (.a or .dylib or .framework) i will give it a try tomorrow, else i will look at it next week.

check dependencies of libraries with "otool -L"

sounds cool.

everything you made till now was great, so i think the community can wait.

(i think i will not be able to manage things mentioned above on my own )

thx a lot!

regards,

claas

[cc_julian]

progress on atlas.

got most of it to compile after some work, remaining problems:

• whats with the DEVIL dependency in DDT.cpp, is this really necessary?

• XMP.cpp, whats all this xercesc stuff?

• archiveviewer.cpp:464, gcc complains:

/Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464:0 /Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464: error: no matching function for call to 'std::set<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >::insert(wxCStrData)'

/Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:304:0 /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:304: note: candidates are: std::pair<typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const _Key&) [with _Key = std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, _Compare = std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, _Alloc = std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >]

/Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:331:0 /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:331: note: typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator std::set<_Key, _Compare, _Alloc>::insert(typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, const _Key&) [with _Key = std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, _Compare = std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, _Alloc = std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >]

[historic_bruno]

progress on atlas.

got most of it to compile after some work, remaining problems:

• whats with the DEVIL dependency in DDT.cpp, is this really necessary?

• XMP.cpp, whats all this xercesc stuff?

• archiveviewer.cpp:464, gcc complains:

The Atlas code is shared among several utilities (such as AoE3Ed) which aren't built by default. I would guess all the above are optional.

/Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464:0 /Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464: error: no matching function for call to 'std::set<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >::insert(wxCStrData)'

Looks like the problem where we want to initialize a std::wstring with a wxString and use c_str() instead of wc_str(). Possibly worth fixing, but see the above

[historic_bruno]

I believe Atlas in particular requires source\tools\atlas\AtlasUI built as a shared library (libAtlasUI) that ends up in binaries\system and which is dependent on source\tools\atlas\AtlasObject and source\tools\atlas\AtlasScript and of course source\tools\atlas\GameInterface (gets built in any case). All the rest is optional as far as I know, but if you want you can include the ActorEditor project which should create a separate binary. Hope this sheds some light on the situation

[Ykkrosh]

Yeah, the stuff that premake4.lua wraps in 'if _OPTIONS["aoe3ed"]' shouldn't be compiled and isn't expected to be portable.

[cc_julian]

ok thanks got it too compile. weirdly changing c_str() to wc_str() doesn't fix the archiveviewer issue, but as you noted we don't need that file ;-)

although it compiles now, it doesn't link ;( the atlas stuff depends on all the core stuff like CRenderer and CSimulation2 etc. what to do here? can't include these sources in the dll for atlas, as that would lead to duplicate symbols when loading it, or?

anyway, i am off for the weekend

[Ykkrosh]

The source in tools/atlas/GameInterface shouldn't get compiled into the AtlasUI library. (That code is part of the engine; AtlasUI only uses some headers from that location, since it's the other side of the interface.)

[cc_julian]

ok thanks! links mostly now, except for a boost issue. will continue sunday or monday.

[Yves]

ok thanks! links mostly now, except for a boost issue. will continue sunday or monday.

What's wrong with the xcode projects generated by premake?

[cc_julian]

if generating deployable binaries from premake would work, you'd already have those.

[historic_bruno]

I don't think any of our developers are familiar enough with Xcode and OS X development to do that. I personally only have a virtual Mac and have only spent a small amount of time on build issues. Then there are questions of which versions of OS X and architectures do we want to support. I don't see any reason why it can't work, the Xcode projects are just text files and we need to make sure the right bits get thrown in.

Thinking more about the dependencies, I believe we can bundle pre-built libraries for OS X, like we do already for Windows.

[cc_julian]

i got atlas *running* but i don't think it is working as intended. i get this on most things:

source/tools/atlas/AtlasUI/ScenarioEditor/Tools/Common/Tools.cpp(78): assert "tool" failed in SetCurrentTool().

[cc_julian]

ok i have:

changed the linked mac patch to be generated from "svn diff" to be easier apply-able

added a patch needed for compiling atlas to my initial post

uploaded a new xcode project folder that also can build atlas and is improved in some other ways.

please commit these to SVN trunk.

[historic_bruno]

Some questions/comments about the patches (haven't tested the build yet, and won't be able to for a week or so):

http://dl.dropbox.com/u/7221986/0ad_mac_patch.diff

Why do you include ps/Pyrogenesis.h in several source files?

Why the #undef _T in UniDoubler.h? (_T is a macro for wxStrings and shouldn't be mixed with engine definitions in any case, Atlas doesn't know about CStr, which I believe is intentional. Any strings shared between Atlas and the engine use std::string or std::wstring instead).

As a general question, does your build support precompiled headers?

http://dl.dropbox.com/u/7221986/atlas_mac_patch.diff

In Memory.h, it's conventional to name the macro guard after the file, so MEMORY_H.

In AtlasUI, I notice several files have changed <> includes to "", any particular reason for that?

Why is RGBColor renamed to RGBColorVector? (The engine seems to build fine in my tests and Atlas shouldn't conflict with engine code).

[cc_julian]

>Why do you include ps/Pyrogenesis.h in several source files?

i've included pyrogenesis.h in all files that use psLogDir(), which is declared in this header, so i don't know how it could ever compile without it being included

>Why the #undef _T in UniDoubler.h?

i got an warning for an double definition there, and there already were some undefs there so i added it. you can just skip that part because it's just a warning.

>As a general question, does your build support precompiled headers?

yes xcode supports a single precompiled header. i've created the xcode/Sources/_ad_Prefix.pch as the precompiled header

>In Memory.h, it's conventional to name the macro guard after the file, so MEMORY_H.

oh yes sorry, i meant to do that but the namespace name confused me ;-)

>In AtlasUI, I notice several files have changed <> includes to "", any particular reason for that?

consistency. 95% of the WX includes use the local header "" notation, and just very few the system header includes <>. i could just add the wx header directory as a user header directory AND as a system header directory, but that would be kinda ... wrong ... just because a few includes deviate from the others. actually using <> everywhere would be even more "right"

>Why is RGBColor renamed to RGBColorVector?

it conflicts with RGBColor as defined somewhere deep in the headers of the mac version of WX. i bet one could work around this with some namespace things, but i am not that fluent in c++ things.

[Ykkrosh]

i've included pyrogenesis.h in all files that use psLogDir(), which is declared in this header, so i don't know how it could ever compile without it being included

It's included by source/pch/engine/precompiled.h which is included by those source files when building with the correct include paths.

(That's probably a good reason to build with Premake on all platforms, so we don't get unexpected problems due to subtly incorrect build configurations )

[General Octavian]

There is no build folder I have found. IDK where to put xcode project in able to run atlas.

Edited September 28, 2011 by General Octavian

[Echelon9]

I've taken cc_julian's provided Xcode project file and patch diff file, updating each for the r10808 of trunk (i.e. essentially the Alpha 8 release).

xcode.zip

clean-build-mac.diff

Current status (24/12/2011) is:

• Compiles cleanly on Xcode 3.2.6
• Linking produces one error that I would like others' thoughts on resolving

ld: duplicate symbol CCmpPathfinder::HandleMessage(CMessage const&, bool)in /Users/..../Documents/Coding/0ad/trunk/build/xcode/build/0ad.build/Debug/0ad.build/Objects-normal/x86_64/CCmpPathfinder-F1D5D520713D9E44.o 
and /Users/..../Documents/Coding/0ad/trunk/build/xcode/build/0ad.build/Debug/0ad.build/Objects-normal/x86_64/CCmpPathfinder-F1D5D520713D9E44.o
collect2: ld returned 1 exit status
Command /Xcode3/usr/bin/g++-4.2 failed with exit code 1