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

[Eric Bodden]

That is correct.

Eric

On 11/04/07, Mario Mendez <mario at cs.unm.edu> 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
>


-- 
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada