[rfc] Moving Robocop tests to mobile/android/tests
nalexander at mozilla.com
Thu Feb 13 14:02:37 PST 2014
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!
More information about the mobile-firefox-dev