[Driver problem]

saweh, the game works perfectly now using the r300g gallium driver from current mesa master (will be released with mesa 7.9) . Tested on my RV530.

Ubuntu PPA (untested) packages also available here:

https://launchpad.net/~xorg-edgers/+archive/ppa

https://launchpad.net/~xorg-edgers/+archive/radeon

[Build Instruction]

I noticed that the 0ad-unix-build.tar contains some .bat/.dll/.exe/.lib/.vcproj files and win-specific directories that could be removed reducing tar size from 37 to 25 MB, adding to the source/tools/dist/build.sh script some --exclude options:

tar cf $PREFIX-unix-build-temp.tar --exclude='*.bat' --exclude='*.dll' --exclude='*.exe' --exclude='*.lib' --exclude='*.vcproj' --exlude='win' --exclude='win32' --exclude='include-win32' ${PREFIX}/{source,build,libraries/{cxxtest,fcollada,spidermonkey-tip,valgrind},binaries/system/readme.txt,*.txt}

Also why the need for 2 tar files, are they supposed to be eventually released with autonomous update? This make running the "./test" difficult, see comment 3 at:

https://bugs.launchpad.net/getdeb.net/+bug/556356

[Build Instruction]

I noticed that at:

http://trac.wildfiregames.com/wiki/BuildIn...ngLinuxpackages

• libCollada_dbg.so or libCollada.so
  
• libAtlasUI_dbg.so or libAtlasUI.so
  

are needed to be distributed, however pyrogenesis and pyrogenesis_dbg don't dynamically link to them. Are they really needed?

[SpiderMonkey build changes]

OK, thanks for the response.

In this case the page:

http://trac.wildfiregames.com/wiki/BuildInstructions

for Fedora should be upfated to remove the packages:

js js-devel

EDIT: and maybe also *nspr* for all the OS?

[SpiderMonkey build changes]

No.

SpiderMonkey isn't designed around regular stable releases - the versions that have been released are very old, the version that some people are planning to release soon is also very old, and the developers aren't interested in changing that (since they're mainly focused on Firefox; the recommended process for embedding SpiderMonkey is to just pick a recent snapshot and bundle it with your own code, like we do).

The behaviour between versions often changes in incompatible ways, so using a different version to what's in SVN is quite likely to introduce test failures and subtle bugs and network out-of-sync errors. The particular version we're using also has a patch to avoid some thread-safety issues - using a different version means the game will randomly crash or corrupt memory in rare situations, which is not good. So you shouldn't do that

Why do you want it to use the system library?

Packages provided by linux distributions usually prefer to depends on a shared library from another package rather than providing the same library in different packages (e.g. when there is a security problem the distribution only need to update 1 package; also save space on drive).

Debian provides spidermonkey inside xulrunner packages that are already used by other packages. This is what I get on an Ubuntu 10.04:

$ apt-cache rdepends xulrunner-1.9.1
xulrunner-1.9.1
Reverse Depends:
  zekr
  xulrunner-1.9.1-testsuite
  xulrunner-1.9.1-gnome-support
  xul-ext-flashgot
 |xul-ext-flashgot
  xul-ext-firecookie
 |xul-ext-firecookie
  xul-ext-firebug
 |xul-ext-firebug
  videolink
  python-hulahop
 |mozzemberek
  mozilla-nukeimage
  miro
  libgtk2-mozembed-perl
  libgtk-mozembed-ruby1.8
  libgjs0
  libgjs0
  kazehakase-gecko
  galeon
  xulrunner-1.9.1-dev
  xulrunner-1.9.1-dbg
$ apt-cache rdepends xulrunner-1.9.2
xulrunner-1.9.2
Reverse Depends:
  xulrunner-1.9.2-testsuite
  xulrunner-1.9.2-gnome-support
  xiphos
  tuxguitar
  prism
  mozzemberek
  moonlight-plugin-mozilla
  google-gadgets-xul
  gnome-web-photo
  fennec
  eclipse-rcp
  conkeror
  chmsee
  yelp
  xulrunner-1.9.2-dev
  python-gtkmozembed
  libswt-mozilla-gtk-3.5-jni
  couchdb-bin

IIRC some time ago 0ad was able to link to the system spidermonkey.

[SpiderMonkey build changes]

Hi, is there a way to configure 0ad to link to the system SpiderMonkey library rather than the one in the SVN?

[Please bear with us, folks. Some music is available to pass the time.]

I noticed that inside the svn there are also windows binaries that get updated regularly. This make 'svn up' slow and increases the svn tarball. What about moving them to an http server?