Jump to content

precompiled mac version done


cc_julian
 Share

Recommended Posts

  • Replies 104
  • Created
  • Last Reply

Top Posters In This Topic

>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 by JuliusColtranePille
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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> > >]

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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?

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).

Link to comment
Share on other sites

>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.

Link to comment
Share on other sites

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 :))

Link to comment
Share on other sites

  • 2 months later...

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...