On 2/13/2014, 1:55 PM, Chris Kitching wrote:
On 13/02/14 21:32, Nick Alexander wrote:
This would be nice, but I'm not sure Proguard supports "consumers that
are not themselves part of the resulting JAR file". Worth
investigating, for sure.
It doesn't, but that's not a problem.
Proguard maps multiple input jars to multiple output jars. The idea is
you make Robocop's jars be part of the input jar set and use a filtering
rule to siphon the Proguarded-Robocop jars to the proper output
directory. Since you'll now have processed both Fennec and Robocop
together "as one program" as far as Proguard is concerned, it will have
automagically preserved calls between the two, and you no longer need to
have manually told it the list of things in the Fennec jars that Robocop
calls - since Robocop was in the input jar set Proguard now sees all
such calls as internal.
Oh, I see. Thanks, this is clear.
You can then, for release builds, simply drop Robocop from the input jar
set and get slightly improved (But now Robocop-incompatible) output.
There was discussion of this on the original Proguard bug, I believe, if
this remains unclear.
Since your proposed change will make it be the case that both Fennec and
Robocop jars will always be available at the point Proguard is running,
this is now slightly less problematic to implement (At least, it reduces
the amount of required build system wizardry to a level where I can see
how it can straightforwardly be done).
I agree, this is not so hard.
I have been thinking that we should go debug/release builds with only
the latter Proguarded, since the Proguard "contract" is that it should
not change behaviour. (Of course, that's a lie, since reflection, etc
interact with Proguard.)
That's been mentioned before. Due to Fennec's liberal use of the JNI and
other things that need manual annotation to prevent Proguard from eating
them, having no passes of Proguard at all on debug builds is just asking
for someone to forget such an annotation and not notice until much later.
Ooh, thanks for this context. I was irritated that PROGUARD_PASSES=0
runs Proguard; now I understand why. I'll comment as much in
Makefile.in when I'm next in the neighbourhood.
Thanks for valuable context!
Nick
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
