Had to hand-modify makefiles to get libjava to build - did I get configuration options wrong?
Tom Tromey
tromey@redhat.com
Mon Nov 25 17:24:00 GMT 2002
>>>>> "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
More information about the Java
mailing list