Re: Include 0AD, a new fancy 3D RTS
On Tue, Sep 7, 2010 at 10:27 PM, Philip Taylor <email@example.com> wrote:
> Note that the game requires an obsolete version of Premake with lots of
> custom patches - a standard version will fail to work.
> (Ideally the game would upgrade to a recent Premake (and send any
> still-necessary patches upstream), or switch to something like CMake, but
> that's likely to take a fair amount of effort and introduce lots of new
> portability bugs that have been squeezed out of the current system, so we
> haven't been rushing to do that.)
Ouch. That will need to be fixed before it can enter Debian.
> Also we require FCollada with custom patches, to fix some crashes when
> loading certain files, and to fix some memory corruption bugs. So I wouldn't
> suggest replacing it with a random version of FCollada from somewhere else,
> or using our version of it for any other project.
> The problem here is there's no upstream for FCollada any more (the
> developers decided to focus on their commercial work instead), and other
> projects seem to all use their own forks of it. Maybe what we should do is
> set up a new fork as a standalone project (i.e. create a new unofficial
> upstream), give it a proper build system, import the patches from our game
> and from elsewhere and keep it actively maintained, and then distros can
> package that version and other applications can hopefully share it.
> (http://trac.wildfiregames.com/ticket/562 is related to this.)
Ouch. Your plan there sounds like a good idea.
> For SpiderMonkey, we don't need custom patches, but older versions will have
> thread-safety bugs (the API guarantees were changed) and newer versions have
> incompatible APIs. The SpiderMonkey developers aren't interested in doing
> stable releases, and it's a core piece of our game engine so we rely on lots
> of its minor details for correctness and performance. Also there's a good
> chance of multiplayer out-of-sync errors when players have different
> versions of SpiderMonkey.
> Since the game is tightly tied to a specific version, I don't know what
> options would work better than the current approach of bundling the required
I guess we'll have to wait for the situation to change before adding
the game to Debian.
> On a related note: We're probably going to add the NVIDIA Texture Tools
> (http://code.google.com/p/nvidia-texture-tools/) as a dependency in the next
> week or so. But I don't think we need any special versions or patches, so a
> normal package should work and hopefully it won't be a problem. (Since most
> (all?) distros don't have packages for it yet, I'd still like to bundle it
> by default, so people won't have to waste time downloading and installing it
> themselves; but I'll add a flag to use the non-bundled library, for people
> who have a packaged version.)
Please don't bundle it in your source tarball. Instead, make a
separate tarball for dependencies and get folks to download that.
In addition, it sounds like you want to make 0AD only work on nVidia
cards with non-free drivers since this texture tools thing seems to
rely on CUDA?