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.
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
