Yves

I think you're right, I applied the suggested changes made earlier in this thread and didn't investigate further if those are correct. Cache changed from "~/Library/Application Support/0ad/cache" to "~/Library/Caches/0ad" Changed Userconfig from "~/Documents/0ad/config" to "~/Library/Application Support/0ad/config" About Application Support directory: About "Documents" Screenshots, Savegames and User Mod definitely go into that category in my opinion and we should keep them as they are now in our table. I'm not quite sure about the Mods and Logs. My suggestions are as follows... Mods: I agree on "~/Documents/0ad/mods". The user will probably want to download a mod somewhere and copy it to a directory, so we could say he "works with it directly". This directory should also be visible (Library is not). Logs: The user doesn't create logs manually, but he should be able to find them and therefore they should not be in a hidden directory. Another thing: Userconfig root doesn't make sense at all in my opinion because we already have Userconfig and I can't see any relation of Logs to configuration. I've marked this line for removal from the table. Do you agree on the suggested changes? The quotes are from: The Mac Application Environment File System Programming

About four people (Echelon9, historic_bruno, Juicyfruit, Yves, ...?) are currently working on tasks related to the build and deployment environment, which is good in the first place. We should try to get as much benefit from this work as possible. Unfortunately it seems a bit uncoordinated at the moment and I see the danger that in the end someone will have a usable solution without using the other peoples work. That's bad for three reasons. First, it's a waste of resources and time and second, it's demotivating and third, It's likely that this solution wouldn't be an optimal one because good inputs won't be considered. I've had a short chat with Echelon9 about this topic and suggested creating a big picture documentation first. Everyone could contribute to that documentation and once we agree on it, we can split it into several tasks and assign those tasks. That way everyone can contribute and we will most likely have higher quality results earlier. I've started creating such a documentation in the wiki: BuildAndDeploymentEnvironment Please post your Inputs here or add them to the Wiki. I'll continue working on that article because there are still some topics missing.

Bad news about XCode4 support: Premake doesn't seem to really support XCode4. They have one file with a few dozen lines of code that puts all the projects into one workspace, but for everything else, they use the same code as for XCode3. We either have to wait until they support it better or do it ourselves. I think it's better to concentrate on the deployable bundle now and continue working on better XCode support once this is done.

The information from today's meeting: We are going to separate the prebuilt libraries from the game's code and data and keep an own directory for each platform. To get the right precompiled libraries for their system, people will have to do a second svn checkout of the corresponding libraries. The revision of each library will be stored in a file and update-workspaces.sh/update-workspaces.bat will check if the libraries are present and if the versions in the file match the libraries versions. This file will most likely be kept up-to-date manually. This way we avoid unnecessary downloads of precompiled libraries for other systems and reduce download-durations for developers/users and bandwidth requirements on the server. We avoid problems related to outdated libraries with the revision-checking described above.

Currently the design focuses mainly on the development build and allows some limited room(preprocessor directive) for adjusting the deployment. For the future it's probably better to shift this focus a bit and concentrate on a more flexible design which does some runtime checking for finding the directories and maybe also allows customizations after buildtime... so I would tend to the second approach. I'm working on a patch how this could work exactly, but I'll need some more time until it is ready.

I've tried to make a summary of what's been said about the paths and what I've found out. Most of it is how it is at the moment. I think we should put the readonly stuff into the app bundle as shown in the column "Path MAC". I'm wondering if the paths for Userconfig and Logs are right. Why don't we put Userconfig into ~./config/0ad directly and change Logs to ~/.local/share/0ad/logs? Btw. Do you have a better idea for posting tables? The bb-codes seem to be a bit broken and doing the search-and-replacing on the csv is a bit cumbersome. I don't like attaching office documents. NameReadonlyDescriptionPath MACDetermined by/Set where? Game data rootYData-Directory for static game data[bundle]/Contents/Resources/datam_rdata in Paths.cpp User data rootNRoot-Directory for data the user creates with the game (savegames, screenshots etc...)~/.local/share/0adm_Data in Paths.cpp savegame directoryNDirectory where savegames are saved to and loaded from~/.local/share/0ad/savesAs [user data root]/saves in GameSetup.cpp InitVFS screenshot directoryNDirectory where screnshots are saved by the game~/.local/share/0ad/screenshotsAS [user data root]/screenshots in GameSetup.cpp InitVFS Default configYDefaullt config-file which is readonly[bundle]/Contents/Resources/data/configAs [Game data root]/config in GameSetup.cpp IniVFS Userconfig rootNCurrently unclear... why is [Logs] here and not in [user data root]?~/.config/0adAs xdgConfig in Paths.cpp UserconfigNContains user specific configuration settings~/.config/0ad/configm_config = [userconfig root]/config in Paths.cpp LogsNContains logs created by the game~/.config/0ad/logsm_logs = [userconfig root]/logs in Paths.cpp CacheNCache directory~/.cache/0adm_cache ModsYDirectory where „modable“ data is places,,, not quite clear yet how this should work??????

I decided to open a thread about this topic because I think we need to collect the available information somewhere. There are different people who already worked on improvements of Mac support, but we're not yet where we want to be and there are still some missing bits before we can put everything together. This involves different aspects and we will only be successful if we cover all of them or at least the important ones. First let's give an overview for those who didn't look at our build-system in detail: The basics: update-workspaces.sh / update-workspaces.bat: The sh-script on Linux/*nix/OSX runs the compilation of some external dependencies and also premake. On Windows the batchfile only executes premake because most of the dependencies are precompiled. Premake: Premake creates our workspaces (also called solutions or projects) for the different platforms. Currently we support Makefiles, VisualStudio (2005, 2008, 2010), Xcode3, Codeblocks. Workspaces: The workspaces are used for building the code on different platform and also for development with different programs (IDE's). Deployment: For (alpha-)releases we make a special deployment for various reasons. The main reason is that we want to make it easier and more convenient for the user. Everything is precompiled and distributed in appropriate containers for the different operating systems and platforms (e.g. .deb files for debian based linux systems and .exe files for windows etc.). I don't know who exactly does that for which system. OK now our current status: XCode support: Currently we have support for XCode3 but It's not particularly useful as far as I can tell and XCode 4 is already out quite a while. The most current version of premake (4.4beta) supports XCode4, but we don't yet know how well. Premake: We are using premake4.3 with quite a lot of customizations. Upgrading is a lot easier than from premake 3.x to 4.3, but I requires some efforts to reimplement the customizations that are still needed and to test everything. Here's a list I made in a few minutes... but It's probably not complete. General: Customizations for using nasm assembler. It's not needed anymore, but the customizations are still in our code... General: PCHHeader as „path“ instead of „string“ in api.lua Windows: trimmprefix for removing the „source“-prefix Makefiles: Fix for parallel builds Makefiles: Test generation Linux+Makefiles, Codeblocks: --start-group and –end-group to work around circular referencing Codeblocks: Fix Codeblocks not relinking after static libraries change (changeset 10814) Workaround some linking problems for ActorEditor, ArchiveViewer and FileConverter (changeset 10749) ... maybe forgot some Build-process on the Mac: The build-process used during development generally works. There's one little problem because both the Makefiles and XCode generate a .app bundle that does not work. You have to copy the binary inside the app-bundle to /binaries/system before it can be executed properly. Deployment process on the Mac: We currently don't have one. We just link to the development build-instructions and sometimes there are people on the forums who create a .app bundle. Tickets: There are currently at least two open tickets about this topic: #947 1073 The patches in both tickets don't offer completed solutions yet. Next steps / open questions XCode support: I think we must still stick to premake and should not use manually created XCode projects. Changing one workspace manually is error-prone and time-consuming. I've created a quick-and-dirty integration of the premake4.4beta and sent it to historic_bruno because he has XCode4 and knows what to check. He will test if it's worth the efforts of upgrading. Build-process on the Mac: Changing the kind of our WindowedApp-Projects to "ConsoleApp" in premake4.lua causes XCode and the Makefiles to generated simple binaries instead of the broken .app bundles on OSX. That's a quick fix and we just need to test if we can change this settings on all environments or if we should do it just for the Mac. Deployment process on the Mac: I've discussed this with historic_bruno and we both think that we should seperate the deployment from the build-system. It's something that should come after everything is build and the build-process should stay as it is for development. I've red some documentation about .app bundles and started creating a shell-script to but one together. We aren't sure if we should put everything into a single .app bundle or if we should use more advanced packaging tools. I think we have to do the .app bundle anyway, because those packages seem to be just some kind of container. If there are no important downsides of "simple" .app bundles, we should avoid the additional complexity added by the packager. One important question that could make a decision obsolete is where we want to put the different resources like the data-directory. We know about two potentially suitable locations: 1. The Resources directory of the .app bundle 2. Library/Application Support/0AD/ I tend to the first because of two reasons: 1. According to the Bundle Programming Guide a bundle should contain all resources required to run propperly. 2. Having anything outside the bundle forces us to use the packager. Code for resource-paths: We definitely have to make some changes to source/ps/GameSetup/Paths.cpp about the location where it tries to find the data-directory and other directories. Echelon9 proposed something about that in his patch. I think we should do something like that for the default behaviour on the Mac (either for Library/Application Support/0AD/ or the bundle's Resources-folder) and in addition add some possibilities to override the default behaviour by command-line parameters or environment variables. Prebuilt libraries: I don't know which libraries need to be prebuilt yet and it will require more work and more testing. One important thing is that the libraries should be compatible for different versions of OSX (which?) and 32 and 64 bit. The Bundle Programming Guide states I'm not sure if that's something that can be done with the bundles or if it just means using universal binaries. What do you think? Probably that's a topic we could also discuss on our team-meeting.

Still needs some improvements until we can replace the current rendering with that

We need an ASCII-art rendering mode for the real nostalgic feelings!

That looks much better . You should run pyrogenesis.app instead of test.app... but this one will crash too because it won't be able to find a few libraries like libmozjs185-ps-release.1.0.dylib. That's a know problem and the easiest way for you to solve it is copying the binary (pyrogenesis) out of pyrogenesis.app directly to 0ad/binaries/system/ and running it from there.

I think this problem could probably be solved by Revision 10858. Could you please get an updated version of the game and test with this one? How to do this: There's a prebuilt version for windows, so you can just execute pyrogenesis.exe in 0ad\binaries\system once you have downloaded it and don't need to build the game from source. Btw. here are the full Build Instructions, but you just need the part I quoted.

... and did it solve the problem?

I can spot two differences in these paths... The one in the logfile: /Library/Frameworks//OpenAL.framework/OpenAL The one you checked with "file": /System/Library/Frameworks/OpenAL.framework/OpenAL The double-slash seems strange. I've googled this path (/Library/Frameworks//OpenAL.framework/OpenAL) and found out that some other people have this error too with other software. One example: https://trac.macports.org/ticket/23222 "/System/Library/Frameworks/OpenAL.framework/OpenAL" seems to be the right path. I don't know if removing the other one is a good idea or not.

Actually the same error is still present... ld: warning: ignoring file /Library/Frameworks//OpenAL.framework/OpenAL, file was built for unsupported file format which is not the architecture being linked (x86_64)

The output you posted does not contain the error messages. Could you please post the entire output?

I don't understand what you exactly mean. Could you please post all lines related to 0ad in /etc/apt/sources.list and the whole /etc/apt/sources.list.d/wfg-0ad-natty.list? And please also tell us which version of Ubuntu you are using.

ld: warning: ignoring file /Library/Frameworks//OpenAL.framework/OpenAL, file was built for unsupported file format which is not the architecture being linked (x86_64) ld: warning: ignoring file /System/Library/Frameworks//QuickTime.framework/QuickTime, file was built for unsupported file format which is not the architecture being linked Apparently it can't find those libraries in 64 bit version. That's either because there aren't any or because it doesn't look at the right place. Can you find a 64 bit version of those Frameworks on your system? Use the "file"-command to determine the architecture of libraries and objectfiles. Unfortunately I don't know the mac very well and don't have a lion-system to make any tests.

Does "svn up" only return "Revision 10836." or does it still download anything? And does the file 0ad/libraries/fcollada/src/FColladaPlugins/FArchiveXML/FArchiveXML.cpp exist?

Hmm I don't know exactly what the problem is and I'm still trying to find it out... but you could run clean-workspaces.sh again and then update-workspaces.sh -j1 in the meantime and post the output. This could probably also solve the problem.

try running svn up in /Users/me/0ad

Are you sure the sources are complete? Did you get them from subversion?

Which operating system are you using? Please post system_info.txt. This extension is part of the opengl compatibility context. I'm quite sure it's supported by the hardware, but probably there's a driver or opengl related problem on your system.

I agree that this looks like a driver problem. You can get a lot information from nVidia directly about installing drivers correctly and solving driver problems. What they are suggesting... I think that's a good place to start.

I think I can be there... even though it's New Year's Eve.

I've had this too on a snow leopard. As far as I remember I solved it by reinstalling xcode. Maybe this could also be interesting for you.