[Soot-list] Re(de)compilation of unmodified .class files

Mario Mendez mario at cs.unm.edu
Wed Apr 11 18:04:15 EDT 2007


So I conclude that there is no automatic way of processing only those 
.class that changed since last Soot run, i.e.: automatically decide by 
Soot that application classes are those that changed and library classes 
are those that didn't.
Is that right?


Patrick Lam wrote:
> Mario Mendez wrote:
>> For each .class C I want to generate another file C' in some arbitrary
>> representation. So, for the example described so far, if the application
>> is just files A and B, I will output A' and B'. Therefore, if B did not
>> change, there is no point in generating the same B' again.
>>
>> Summary of my goal, then: for each classfile C that did change since
>> last compilation, I want to generate a C'. That is independent of
>> whether C is an application or library class: if it can be reached from
>> the main and it changed, I would like to run my Transformer on it.
>>
>> The question, again, is whether this "on-demand" transform is provided
>> already in Soot in some way.
> 
> I still don't know what you're doing with each class, say A or B.  When
> you read A, do you need information about B or not?  If you don't, then
> you can set B to be a library class, i.e. you can explicitly specify the
> classes that you want to transform by only passing the changed classes
> to Soot.
> 
> Soot does not have any notion of changed classes. You'd have to
> implement it yourself. But it's not clear that it matters, because you
> don't know what's taking a lot of time in your case.
> 
> pat


More information about the Soot-list mailing list