Re: Had to hand-modify makefiles to get libjava to build - did I get configuration options wrong?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Scott" == Scott Gilbertson <scottg@mantatest.com> writes:

Tom> More precisely, nobody is maintaining the xlib peers.  They
Tom> haven't compiled in quite some time.

Scott> OK. I'll live with the requirement to hand-modify the makefile for the
Scott> moment.

If you send a clean patch to Makefile.am I will check it in :-)
I hate to think that hand-modifying the Makefile is something anybody
needs to do.

Scott> I guess saying that I need the xlib peers is the same as
Scott> volunteering to work on them.  So far, however, I've found they
Scott> work pretty well other than the compile issue (unless the peers
Scott> are what's causing my crashes).  I did, however, notice that
Scott> XCanvasPeer.setVisible doesn't implement unmap, and I couldn't
Scott> see why not, so the code I'm testing includes that (but I don't
Scott> think it's getting called in my app any more).

Patches like this would also be accepted.

Scott> Early tests indicate that compiling with gcj will get us the
Scott> performance we need to make up for the puny cache in the CPU
Scott> (National Geode - 16k cache).  My general approach is to make
Scott> everything lightweight except the enclosing Frame, so the peers
Scott> don't have a whole lot to do.  All my widgets are custom, with
Scott> either Component or Container as the base class, so I'm happy
Scott> to include bizzarre-looking code in my application to work
Scott> within libjava's limitations.

Nice.

Scott> When I get all this working, it will be accurate to claim that
Scott> a real live useful AWT application works with gcj.

Strange, but cool.  Please consider writing a `done with gcj' post for
the web page.

Tom