Re: [q-lang-users] [qlist] Re: SDL anyone?

[Andrew B. <and...@ya...>]

On 2 Jan 2007, at 23:49, Albert Graef wrote:

>
> You can tell SWIG to ignore various parts of the interface. But if you
> have a Linux system I'd suggest using that for development; it's  
> usually
> the least problematic, and porting quirks can be ironed out later. I
> have some experience with that, at least on Windows. ;-)

The only Linux box I have access to right now is running the 64 bit  
version of Ubuntu.  I never have gotten any 32 bit binaries to work  
on it, nor does q.  It also runs X, but no window manager nor  
anything fancy like a OpenGL library.

>
> Well, writing a C wrapper module is one solution (I also did that with
> that xine module, IIRC), but it kind of defeats the purpose of using
> SWIG. If the SDL header files are too messy, then it's also  
> possible to
> just provide the prototypes of types and functions that are to be
> wrapped in the .i file, or selectively replace some of the  
> functions of
> the interface while retaining others. You can find examples of this in
> the sqlite3 and opengl wrappers.

Wrapping the functions is straightforward.  I have not yet found  
anything in there that will make SWIG unhappy.  The difficulty is  
that they have a macro which changes "main" into "sdl_main" so that  
the application's "main" gets called from inside the sdl library.   
Instead, a "winmain" within their code gets called by the OS.  This  
is required in Windows and MacOS because GUI programs have a  
different entry point than console apps do.  Under X, there is no  
difference, so the Linux build does not have this requirement.

>
> But I would first try to just %include all the relevant header  
> files in
> your .i file and see what q-swig generates from that. Take a look  
> at the
> generated .q source and maybe the _wrap.c file, and try the most
> important operations (e.g., initialization, finalization) in Q. If
> something doesn't work as it should then you can start working from
> that, replacing broken wrapper functions with your own code. That's  
> the
> way we did it with the opengl and openal interfaces, and I guess it's
> the only way to stay sane when trying to wrap bigger libraries. ;-)

Yep, that is exactly my plan.  But until I have a .exe which has a  
chance of successfully calling any of those functions, there is  
little point, IMHO.

-andrew