[rfc] Moving Robocop tests to mobile/android/tests

Nick Alexander 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!
Nick


More information about the mobile-firefox-dev mailing list