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?
_______________________________________________
Classpath-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath-patches
