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

[Alexandre Courbot]

> Other than that it compiled and installed fine :). Runs well too,
> although it prints "Oki Doki" twice for each keypress. Once for the key
> press and once for the release?

Exactly. Of course, since the event isn't passed to the callback, you
can't make the difference between keypress and keyrelease events yet.

> On yet a different matter: running the stuff under MacOS X:

Ouchie :)

> First of all, during compilation I got a number of warnings like the
> following:
> 
> *** Warning: linker path does not have real file for library -lSDLmain.
> *** I have the capability to make that library automatically link in
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libSDLmain and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib/libSDLmain.a
> 
> *** Warning: linker path does not have real file for library -lstdc++.
> *** I have the capability to make that library automatically link in
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libstdc++ and none of the candidates passed a file format test
> *** using a file magic. Last file checked:
> /usr/lib/gcc/darwin/default/libstdc++.a
> 
> *** Warning: libtool could not satisfy all declared inter-library
> *** dependencies of module sdl.  Therefore, libtool will create
> *** a static module, that should work as long as the dlopening
> *** application is linked with the -dlopen flag.
> 
> Not sure what that means (but it might explain why stuff didn't run in
> the end).

Yeah, this is something serious. Let me explain how backends work.
Ideally, every backend is compiled as a shared library that is installed
to $prefix/lib/adonthell/gfx for gfx backends for instance. At init
time, the gfx module just loads the requested backend. Not every system
does support shared libraries however, that's why is has been made
possible to link statically all backends when dynamic libs aren't
available. The -dlopen option is there for that, and I haven't used it.
Of course, you'd have a name clash doing so, that's why libltdl allows
you to give a unique name made with the backend name to all your
exported objects. Look at the sdl gfx backend for instance.

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...

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.

> And as said above, when trying to run the script, it failed:
> 
> Traceback (most recent call last):
>   File "test.py", line 1, in ?
>     from adonthell import gfx, input, python
>   File "/tmp/adonthell/lib/python2.2/site-packages/adonthell/gfx.py",
> line 4, in ?
>     import _gfx
> ImportError: No module named _gfx
> 
> But a module called _gfx.a is there, just like on Linux. (Which makes me
> wonder: shouldn't that be a _gfx.so instead?)

Yup. Obviouly, you can't load dynamically a static library! ;)

> 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?

Alex.
PS: the package is updated if you want to test whether everything
compiles well now.
-- 
http://www.gnurou.org