On Friday 06 January 2006 10:07, Casey Marshall wrote:
> After thinking about exportability a little more, I think the best
> option may be to not provide any `--disable-crypto' option at all,
> and just structure the source code so that packagers can remove all
> non-exportable crypto by just removing whole directories. The build
> system doesn't care if you remove an entire package, anyway.
>
> This is a little closer to what Raif suggested, but I'd suggest not
> doing it by splitting the hierarchy up. That is, instead of making
> the boundary:
>
> <root>/gnu/javax/crypto/prng <-- weak algs
> <root>/non-export/gnu/javax/crypto/prng <-- strong algs
>
> We just shove exportable algorithms and providers under `gnu/java/
> security,' and non-exportable algorithms and providers under `gnu/
> javax/crypto.' Thus, if you need to make an exportable source/binary,
> just `rm -rf {,gnu/}javax/crypto.' It's more of a manual process, but
> very easy.
>
> How does this sound?how do you address the Factory classes? a Factory for a split "service" must see all its subordinates, which are different depending on whether the non-exportable stuff is in or out. yes? -- cheers; rsn
pgp3acPMgVzBB.pgp
Description: PGP signature
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
