cc_julian

the files i've posted some years back are offline now but i placed a copy here in case something in there is still of interest: http://s000.tinyupload.com/?file_id=36564605789805633113

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

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.

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

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

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

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

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

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"

>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

read the post you quoted again

i've updated all 3 files and can confirm it "working" now. there are some remaining problems though • game freezes for a few seconds or even minutes after loading a map (and being sluggish even afterwards), may be related to having to use the debug version of the javascript library cause of linker issues • i've seen the game hang in opengl code on lion for both of these issues it would be good to set the game to windowed mode in the config file in Library/Application Support/0AD/config/ i'll look at these later on.

ok thanks, but the version has the collada problem, i will have an fixed version in a few minutes.

yes, just a few minutes.

i'll have a look EDIT: found the problem, this was already working, will fix it soon. just FYI, saying something like "it fails" is completely useless at it doesn't give any information on what the actual problem is means the files couldnt be found, means you didn't put the xcode folder into the build folder of the 0ad sources. the xcode project is meant for *developers*

must be a problem with the collada plugin, works here, what system are u on?

doesn't my first post contain detailed instructions, what else do you need? actually the binary is meant to be mirrored by the powers-that-be and not to be downloaded directly by users dropbox doesn't like much bandwidth.

might be difficult, since even just installing macports might make built libraries "silently" dependent on in and therefore non-deployable. libpng is included with macosx anyway, enet didnt update in the last 5 years, boost isn't security relevant, and probably nvtt neither. leaves us with libjpeg and mozjs. i bet i can build those libraries 50 times in the time it takes to build a system that automatically generates deployable binaries from their latest versions.

i am glad if its of use if someone provides prebuilt versions of the dependencies (boost, enet, collada, libjpeg, mozjs, nvtt), i'd be happy to update the project to support 32 bit and 10.5 i know generating project files is popular right now, but in my opinion it just doesnt work and i don't have an interest to spend a single minute on using premake/cmake/whatever or even messing with sucky generated projects you can of course continue using premake, and just use my xcode project if you want to create deployable DMGs, that would be the least effort the solution here is just to pre-build the dependencies once and include the pre-built libraries, so its easy to build for everyone hm ok but storing files in ~./local/ on Mac OS X is just wrong, regardless how the binary is being built ;-) i suggest making the data path change only for the xcode build, but the location of the folder where files are being written to should be changed for all Mac OS X builds. i've done just that in the linked patch and xcode folder. if you want the other path change to be only for the xcode builds too, just change __APPLE__ to MAC_NATIVE

BTW: i've completely ignored the existing build system (premake) and instead created an xcode version from scratch. using something other than xcode always has difficulties creating something that is actually deployable to end-users. of course i generated stand-alone versions of all dependent libraries too - again, using macports installed versions would lead to dependencies that make deployment impossible.

hey i came across the 0ad alpha 7 announcement today, was encouraged by the fat "Instructions for Mac OS" button, but as you all know it only leads only to an compilation instructions site instead of precompiled downloads. i've therefore spent some time creating: • a distributable binary version of 0ad alpha 7 for Mac OS X • an xcode project and assorted support infrastructure for 0ad that makes creating distributable binary mac versions easy 1.) here is a very small patch for 0ad that fixes some compile errors (pyrogenesis.h is needed for the psLogDir declaration) and fixes up the runtime paths so that 0ad reads the data files from inside its application bundle (because we have a proper double clickable moveable app now) and also uses better paths for storing preferences. you could also change the ifdefs from __APPLE__ to something we define in _ad_Prefix.pch if you don't want these path changes to apply to mac versions built from the command line http://dl.dropbox.co..._mac_patch.diff http://dl.dropbox.com/u/7221986/atlas_mac_patch.diff 2.) here is an zipped folder containing an xcode project for building 0ad and misc support files including pre-built libraries etc etc. this should be added to the build/ folder http://dl.dropbox.co...d_mac_xcode.zip 3.) here is a pre-built deployable version of 0AD beta 7 - i've personally tested it on an NVIDIA equipped MacPro with 10.6.6 and an ATI equipped iMac with 10.7.1 0ad-r10288-alpha-mac.dmg ___ for building deployable binaries yourself you just need to open the build/xcode/0ad.xcodeproj in Xcode 3.2 (4.x may also work, but is untested), select the "Release" configuration and hit "Build" from the "Build" menu. this will create the "0 A.D." application. now just right click it, select "show package contents" and add the *complete* "data" folder into the application bundle, because without data the binary won't run ;-) now zip the result or make a DMG with Disk Utility. EDIT: boost_1_47_0 must also be downloaded and decompressed into the xcode folder __ the generated binary runs on Mac OS X 10.6 or later and only on 64-bit Macs. i don't consider the requirements problematic, 10.5 is unsupported by apple themselves by now, and apple only shipped very few 32-bit intel macs, most of which additionally only have sucky integrated GPUs like the GMA 950 and are barely able to run a game anyway. it would be easy to create a version that runs on 32 bit and 10.5 too, would just require a few hours creating updated version of the library dependencies, and a few changes to the xcode project bye, julian