>>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> I thought you meant it to be a way for the VM to select which Mark> AWT implementation to select. That's definitely part of my intention. A patch like that one will go in libgcj eventually. We already have a couple peer implementations (the xlib one seems to have been partially resurrected). I'd like to set things up so that the default one is chosen by configure, and ideally I'd like to share AWT 100% with Classpath. Maintaining one little divergence is no problem though. Mark> And if that is the case then I would like to see one level of Mark> indirection (either a System property or a VM method) to select Mark> the desired Toolkit class. Why is that? I suppose one idea would be that you could compile Classpath once and use it for all (non-libgcj) VMs. That does make sense as a goal. OTOH there is already one bit of Configuration.java that is VM-specific, namely INIT_LOAD_LIBRARY. But perhaps since it is fairly gcj-specific, it doesn't count. Mark> Currently only specific VMs might have different AWT Mark> implementations and in that case I don't think adding this to Mark> Configure.java.in is a good idea. I'd like to understand this better. And ideally I'd like the rationale to be documented. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
