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

[Chris Pickett]

Probably not.

You might want to do some profiling first to find out which steps and 
which classes are taking up all the time in your current setup...

One thing you might not realize is that even if a given class does not 
change, changes in other classes can still affect that class for 
interprocedural analyses.

It pretty much sounds like you want to do "incremental compilation", but 
I don't know if you really need to do it for your application, or if 
you're just guessing that it would be a good thing to have.

Often, for experimental purposes, it can be better to accept slow 
compilation times than invest a lot of effort in designing a really 
efficient system.  For me, 10 minutes to read in all application and 
library class files, do interprocedural points-to analysis and build a 
call graph, and then apply analyses and transformations before writing 
everything out to disk is actually pretty reasonable.

Chris

Mario Mendez wrote:
> 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
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list