On Tue, Sep 7, 2010 at 10:27 PM, Philip Taylor <[email protected]> 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 > version. 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? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
