Re: [Adonthell-devel] New structure status, thoughts, and problems

[Kai Sterker]

On Sat, 22 Mar 2003 20:16:03 +0100 Alexandre Courbot wrote:

> In your case, it looks like libtool had some problems with SDLmain and
> stdc++, and choose to revert to static linking. Which of course
> couldn't work since I omitted the -dlopen option. The reason is the
> following: if I put it, the adonthell_gfx library will need the
> backends to be built, since -dlopen will point to them. However, the
> backends must be build*after* adonthell_gfx, because they call methods
> from it and must be linked with it (otherwise you get an error at load
> time). There is probably a solution to this. Not that it is important
> that Adonthell runs on systems that only support static linking, but
> it probably can help in some cases. Of course, you'll probably want to
> use dynamic linking...

Guess I'll have to do some reading on this subject, as I don't
understand much of it. I'll also have to see why it does not find the
dynamic stdc++ and SDL libraries. 
 

> As for the Python.h problem: it should be solved now. If you have
> looked at the include policy, all the included files (excepted
> backends) include headers with the src/ directory as root. This should
> be sufficient to prevent such problems, but by default the . directory
> is in the include path. I've removed it, so now it should work well.

It's still there: the Makefile.am has an entry called

DEFAULT_INCLUDES = -I$(srcdir) -I$(top_builddir)

And $srcdir is defined as '.'. Even when removing it, it's still not
working, even though there's no more -I. in the argument list.

However, it works when replacing -I$(srcdir) in the line above with -I-
. In that case however, python/callback.h must include "base/callback.h"
instead of "../base/callback.h".

That's working on both Linux and OSX, so it should be safe.


> > On the topic of passing arguments to the callback: maybe a template
> > will help. But I'm not sure. I'll look into it some more.
> 
> I don't think it would help much. I'll detail what we'd need for, say,
> the input callback mechanism:
> 
> input::listeners will want to run the callback associated to a certain
> kind of events when they are triggered by the input::manager. Of
> course, when called, the callback must be aware of the event that has
> been triggered. Like, in case of a keyboard_event, which key is
> concerned and whether it was pushed or released. So when running the
> callback, it*must* take a pointer to this event as a parameter to be
> useful. As you said, a template system would perfectly do the trick...
> on C++ side.
> 
> As you can see, python::callback inherits from base::callback, and
> callback calling is virtual in base::callback. If we start making
> templates, we'll lose this useful inheritance relationship which makes
> it possible to create a Python callback so easily. Not to mention, of
> course, that any arguments and their types should be defined at the
> base class level, since it's this one that is called by the listeners.
> 
> One solution I can see it to use pointers ignominies and monstruous
> castings. I'd like to avoid this as much as possible. Suggestions?

Not at present. I had a look at the current (C++) callback code, and to
me it seems to be about the only way to allow for (almost) any kind of
arguments. Unless you define a unique run method for each possible
argument type. Which of course will also couse problems on python side,
as polymorphism isn't supported (SWIG sorta supports it by renaming
methods, but that makes things less simple).


> PS: the package is updated if you want to test whether everything
> compiles well now.

Yeah, no more problems now :).

Kai