Casey Marshall wrote:
> On Dec 27, 2005, at 8:49 AM, Raif S. Naffah wrote:
> I'd prefer to keep ".in" files to a minimum. We could attain the same
> thing by using reflection for the parts that may or may not be
> available or are disabled at compile time.
Yes, please. I'd also like to avoid having more *.java.in files than
>> * when classes from GNU Crypto, rely on AWT or Swing, they will be
>> re-written as templates conditioned by existing Classpath configuration
> Why is that needed? Aren't AWT and Swing still available, even if no
> native peers are compiled?
Yes, they are still available. The AWTCallbackHandler may not work
properly without a peer implementation, but that should be the concern
of the person disabling the native peers. For example, the user may want
to supply their own peer implementation, instead of GNU classpath's
> Are there any opinions about adding test suites to Classpath? It seems
> to me like that had been abandoned in favor of an external test suite
I'd prefer to see all tests go into Mauve. It is much easier to use than
runtime/library specific test suites, as anyone who has tried to run
kaffe with libgcj's test suite or vice versa can confirm, I guess :)
> I had put together my own proposed patch set, and sent a message about
> it from an address that needs approval for classpath-patches (I'm
> writing this over a slow VNC connection). It's rather simpler than
> this, and mostly just involves renaming gnu.crypto to gnu.javax.crypto,
> and org.metastatic.jessie to gnu.javax.net.ssl, and adds a configure
> switch to disable compiling crypto classes (I'd rather avoid doing a
> lot to support export control, because AFAIK only one person needs it
> (sorry, Anthony ;-) and it is more infrastructure to maintain). It may
> make sense to "bifurcate" GNU Crypto into "weak" and "strong"
> eventually, however.
> The patch is at <http://metastatic.org/source/gnu-crypto- jessie.patch>
> and a tarball of new files at <http://metastatic.org/ > source/gnu-crypto-jesise.tar.gz>.