Re: [abc] soot doesn't build against recent polyglot

On Tue, Dec 21, 2004 at 11:14:31PM +0000, Ganesh Sittampalam wrote:
> [Jennifer/Ondrej: if you think this would be better discussed on soot-list
> we can move the discussion there. I thought I'd try out the soot bugzilla,

I don't think it has much to do with Soot itself; rather, it's an abc
team communication issue. So, I think this (abc@...) is the right place
to discuss it.

> but entering bugs on it doesn't actually work.]

I've added components to the bugzilla and successfully added a test bug.
Does it work for you now? If not, what doesn't work?

> Latest soot SVN doesn't build against the version of Polyglot abc
> currently uses, because polyglot.frontend.FileSource was changed on 2
> November to not have a constructor that takes a String any more.
>
> This is a bit of a problem for abc, since I think we are probably at least
> somewhat tied to that version of Polyglot, although Oege could answer this
> more definitively. I'm not entirely sure how we got away with this in the
> overnight test runs etc up till now, given that we must have been using a
> soot jar that referred to the non-existent constructor in the polyglot jar
> (ant's inadequate update checking would explain why soot continued to
> compile).

Hmm, yes, we should probably have nightlies that catch this sort of
thing.

The released Soot 2.2.0 builds against the released Polyglot 1.3. The
purpose of Soot releases is so that students using and modifying Soot
in courses do not have to track Subversion/CVS. Unlike abc users, Soot
users are expected to be actively modifying and recompiling the code, so
having all the students using the same well-defined released version is
necessary to avoid a nightmare for TAs and profs. This is why a released
Soot depends on released dependencies.

The Soot in the Subversion repository currently builds against the
released Polyglot 1.3. If there is a very good reason to, we could
change the policy to make the current Subversion Soot depend on the
current CVS Polyglot, and fix it to match any changes in Polyglot
as they happen. However, this has serious disadvantages for Soot,
its users, and for Laurie and her TAs (which includes us...). In
particular, this makes Soot dependent on the Polyglot maintainers for
releases: in order to do a Soot release, we will have to wait for a
Polyglot release. One of the things we're trying to do with the recent
improvements in the Soot build process is have more frequent Soot
releases. Tracking Polyglot CVS could undermine that goal. For instance,
Jennifer indicated that she wants to do a Soot release supporting
Eclipse 3.0 in early January; having to wait for a new Polyglot would
delay that. An additional disadvantage of tracking the Polyglot CVS is
that it's more work for the Soot maintainers, but it is probably doable.

However, neither Polyglot 1.3 nor the current CVS Polyglot is the one
that is on musketeer that abc uses, so both of the above options would
still require a change in abc policy. I don't think it is reasonable to
ask users of the Subversion Soot to e-mail Ganesh or Oege to get the
current abc-approved version of Polyglot each time they want to compile
Soot.

Another alternative would be for us to make our own Polyglot releases.
However, this may understandably annoy the Polyglot team. Furthermore,
we are stretched rather thin as it is; who precisely would the "us" be?

Yet another alternative, if abc really needs a bleeding-edge Polyglot,
would be to maintain an abc-specific branch of Soot. Subversion makes
maintaining such branches quite feasible. Is this additional maintenance
work a worthwhile price to pay for insisting on bleeding-edge software?

> Anyway, is this something that can reasonably be fixed in Soot? I don't
> know if you try to track latest polyglot CVS or the latest release,
> although I think in this case it can be fixed in a way that would be
> compatible with either.

You suggest that for the short term, it may be possible to devise a Soot
that would work with both the released and the CVS Polyglot. That would
postpone the problem for the moment, and I would have no problem with
such a change. But it's only a stop-gap measure until Polyglot comes up
with a change that does not make such a thing possible.

I don't know that any of the options I've outlined above will satisfy
everyone. So, we need to discuss it and come up with something everyone
can live with. The option best for Soot, (which is depending on the
released Polyglot), may not be acceptable to abc. But it may be that
I am mistaken that people want Soot releases more often (although the
soot-list indicates otherwise). Or it may be that Laurie is willing to
teach with students all fetching stuff from CVS. Or it may be that the
Polyglot folks would be happy to have us act as their release managers.
I don't know, so I'm interested in comments.

Since all of this is closely related to the frequency of Polyglot
releases, it may make sense to ask the Polyglot gang about their
expected release frequency.

Ondrej
Received on Wed Dec 22 17:15:25 2004