[Wxruby-dev] RE: wxWindows for Ruby Again

[Curt Hibbs]

Tobias Peters wrote:
>
> On Fri, 20 Sep 2002, Park Heesob wrote:
>
> > Because I tested only in Windows XP.
> > It needs some modifications for other platforms.
> >
> > > Curt
>
> I just downloaded it and tried to compile on linux. extconf.rb contains
> visual c++ specific stuff. I replaced it with:
>
> require 'mkmf'
> $CFLAGS += `wx-config --cflags`
> $libs += `wx-config --libs`
> create_makefile('wx')
>
> then compilation fails with
>
> g++ -fPIC -g -O2 -I/usr/X11R6/lib/wx/include/gtk-2.2 -I/usr/X11R6/include
> -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_REENTRANT
> -I/home/tobias/lib/ruby/1.6/i686-linux -I. -I/home/tobias/include    -c -o
> wx_wrap.o wx_wrap.cpp
> wx_wrap.cpp:1269: wx/tglbtn.h: No such file or directory
> wx_wrap.cpp:1425: wx/fdrepdlg.h: No such file or directory
> wx_wrap.cpp:1491: wx/popupwin.h: No such file or directory
> wx_wrap.cpp:1492: wx/tipwin.h: No such file or directory
>
> I give up here because I don't know anything about wxwindows. Maybe it's
> due to the wx library version:
>
> $ wx-config --version
> 2.2.9
>
> and you state I need wxWindows 1.3.2 .

I am assuming that he really meant to say wxWindows 2.3.2 (which is the most
recent version).

> Thanks for your work, Park!

Yes, definitely!

>   Tobias

Let me say a few words about the approach we are taking in the development
of wxRuby, because it differs from what they did with wxPython.

The problem with the wxPython implementation is that in their interface
files they duplicated all of the definitions in the wxWindows headers files
(in fairness, they may have had no choice as they were using SWIG 1.1). Over
time this becomes a maintenance headache because every time a new version of
wxWindows is released, you have to do a diff to see what changed and then
duplicate those changes in the interface files.

SWIG 1.3.14 (the current version) has a much better implementation of the
c/c++ preprocessor and is, consequently, better able to directly process
header files without the need for interface files. We started with a copy of
the wxPython interface files, intending to port them, but quickly decided to
discard them and try to wrap wxWindows with as little such duplication as
possible.

The existence for Park's working (on windows) port of the wxPython
implementation will probably alter our approach. What I am going to
investigate this weekend, is using Park's port as a working starting point
and then systematically remove the duplications (where possible).

Thanks again, Park!

Curt