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

Chris Kitching chriskitching at linux.com
Thu Feb 13 13:55:14 PST 2014


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.
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).

Also, spectacularly offtopic! Sorry.


> 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.
Of course, the vast majority of work that gets done doesn't involve 
adding/removing such entry points, so maybe the answer is to check for 
such errors in a less expensive way. Bug 944553 
<https://bugzilla.mozilla.org/show_bug.cgi?id=944553>might be a good 
start in that direction (It checks consistency of annotations (where 
possible) independently of Proguard. This seems a nice way of checking 
if you screwed up an annotation without having to wait for such a long 
time). Unsurprisingly, RNewman didn't like the hastily-assembled 
gargantum sed script at the core of that solution.

I digress.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/mobile-firefox-dev/attachments/20140213/c9dfbb60/attachment.html>


More information about the mobile-firefox-dev mailing list