adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Python tests not working anymore


From: Alexandre Courbot
Subject: Re: [Adonthell-devel] Python tests not working anymore
Date: Wed, 4 Feb 2004 13:14:49 +0100
User-agent: KMail/1.6

> I thought about this myself. It might go into base, I guess, but not
> directly into src/:
>
> * First, we'll have several backends for main, as different
> initialization will
>    be needed for different gfx libraries.
> * Second, I thought we might add some more functionality later on, like
> setting
>    the backend to use in the main module, so that all the other modules
> can get
>    it from there. (instead of passing it directly to each module as we
> do now,
>    assuming that we do not want to mix different backends.
> * Finally, I was thinking about a graphical game launcher that would
> appear when
>    starting adonthell (similar to ScummVM), so that people can start any
>    installed game without the need to use the command line. I guess that
> would
>    also go into the main module.

Good points. On the other hand, I can hardly imagine base::init() not 
returning. Although we'd only need to call it from Python, which we'll try to 
get rid of anyway.

So the right policy would be, no source into src/, right?

> SWIG 1.3.19 offers something called director classes. It allows to
> subclass C++ classes on Python side in such a way that C++ knows about
> them. I tried using it to achieve what you suggest, but again had to
> give up on it. The problem is that this feature makes use of C++
> exceptions, which we have turned off. But turning them on did result in
> errors in other modules.

Mmm yeah. Exceptions support is probably not what we'd want in Adonthell 
anyway.

By the way. I've commited stuff a few days ago about SWIG. It removes the 
libswigruntime/ directory (swig runtime library we embedded) and asks SWIG to 
generate it (as of 1.3.21 SWIG is capable of doing it) along with the Python 
wrappers. I did this because, well, it's cleaner, and I had troubles with the 
runtime lib we embedded not being compatible anymore with my own version of 
SWIG. If you have problems building the source, maybe you should switch to 
1.3.21 (I assumed 1.3.20 would support it too when upgrading the required 
version in the configure.in).

Alex.
-- 
http://www.gnurou.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]