A way to disable compilation of dependent projects in Eclipse plugin

On Mon, Jan 25, 2010 at 10:11 AM, Ismael Juma wrote:
> Meanwhile, it would be nice if there was an option "Build dependent
> projects automatically" similar to "Build automatically" that would
> allow one to disable it while working on certain projects.

This only makes sense if the depended-on project is largely
unchanging. In which case you can get the effect you're after by
removing it as a project-level dependency and adding it's output
folder as a class folder dependency.

Cheers,

Miles

On Mon, 2010-01-25 at 10:25 +0000, Miles Sabin wrote:
> On Mon, Jan 25, 2010 at 10:11 AM, Ismael Juma wrote:
> > Meanwhile, it would be nice if there was an option "Build dependent
> > projects automatically" similar to "Build automatically" that would
> > allow one to disable it while working on certain projects.
>
> This only makes sense if the depended-on project is largely
> unchanging.

The issue is that this a dynamic thing (not static) and hence why a
dynamic solution works better. There are times that I know what I'm
changing is mostly project-local and I'd rather do a batch of changes
with much faster project-local compilation and then re-enable everything
and see if anything else broke (in case my assumptions were wrong). But
there are others where I'd prefer the normal mode of operation.

> In which case you can get the effect you're after by
> removing it as a project-level dependency and adding it's output
> folder as a class folder dependency.

How does this work in terms of recompilation? Would I have to manually
recompile the other projects once the depended-on project changes?

Best,
Ismael

On Mon, Jan 25, 2010 at 10:46 AM, Ismael Juma wrote:
> How does this work in terms of recompilation? Would I have to manually
> recompile the other projects once the depended-on project changes?

Yes ... that's what you were asking for, no?

Cheers,

Miles

On Mon, 2010-01-25 at 12:55 +0000, Miles Sabin wrote:
> On Mon, Jan 25, 2010 at 10:46 AM, Ismael Juma wrote:
> > How does this work in terms of recompilation? Would I have to manually
> > recompile the other projects once the depended-on project changes?
>
> Yes ... that's what you were asking for, no?

Not permanently. :) I wanted a convenient way to disable it in certain
situations. Also, I'd like to avoid changing this in the configuration
of the projects as it affects other developers too.

So, after this conversation, the questions I have are:

(1) Do you think it would it be hard to implement something like this?

(2) If not, and if someone implemented it, would you accept it into the
plugin?

(3) Does anyone know the status of the build manager? In particular, are
there known bugs about it recompiling a lot more than needed? (It seems
to compile a lot even when a test is changed where nothing else
references that test. I guess I need to check this more carefully and
file bugs if needed).

(4) Is the suggestion you gave (use build folder instead of project
dependencies) the recommended approach for medium and large codebases
(distributed among a set of small projects)?

(5) Are there any plans to reduce the amount of blocking that happens
due to builds? Ideally there would be no blocking ever, but I understand
that it's not easy to do within Eclipse.

Sorry for the large number of questions. Just trying to work out what
are my options in order to have a productive development environment.

Best,
Ismael

Hmm - this is related to the issue i created
https://lampsvn.epfl.ch/trac/scala/ticket/2937 except you don't have a
problem with just the errors but also the time it takes to recompile.

yes, the editors are sometimes locked - that's why i created that thread
with "it's fast now!" - but I find that behaviour inconsistent.

yes - for some reason, it is a *lot* slower than the Java compiler, again -
especially on multiple projects...

I don't think the 8 cores matter. They may actually make matters worse. You
see, I noticed the thing never uses more than one thread/core, so a faster
thread but less cores CPU would actually be way faster for you than a big
honking 8 cores, which usually makes each core quite slow...

Miles - how can we convince you to use the cores? :) build a dependency tree
and identify parallel compilation branches and ... c'mon, that's cool - but
I guess more of a compiler issue than an eclipse plugin issue.

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

Hmm - this is related to the issue i created
https://lampsvn.epfl.ch/trac/scala/ticket/2937 except you don't have a
problem with just the errors but also the time it takes to recompile.

yes, the editors are sometimes locked - that's why i created that thread
with "it's fast now!" - but I find that behaviour inconsistent.

yes - for some reason, it is a *lot* slower than the Java compiler, again -
especially on multiple projects...

I don't think the 8 cores matter. They may actually make matters worse. You
see, I noticed the thing never uses more than one thread/core, so a faster
thread but less cores CPU would actually be way faster for you than a big
honking 8 cores, which usually makes each core quite slow...

Miles - how can we convince you to use the cores? :) build a dependency tree
and identify parallel compilation branches and ... c'mon, that's cool - but
I guess more of a compiler issue than an eclipse plugin issue.



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

--
View this message in context: http://old.nabble.com/-scala-tools--A-way-to-disable-compilation-of-dependent-projects-in-Eclipse-plugin-tp27304453p27314544.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

On Mon, 2010-01-25 at 14:02 -0800, Razvan Cojocaru wrote:
> I don't think the 8 cores matter. They may actually make matters worse. You
> see, I noticed the thing never uses more than one thread/core

I know that scalac is single-threaded. I was just pointing out that it
wasn't a slow machine.

> so a faster
> thread but less cores CPU would actually be way faster for you than a big
> honking 8 cores, which usually makes each core quite slow...

Actually each core is a decently fast Xeon 5400 series, 2.8 Ghz.

> Miles - how can we convince you to use the cores? :) build a dependency tree
> and identify parallel compilation branches and ... c'mon, that's cool - but
> I guess more of a compiler issue than an eclipse plugin issue.

I seem to recall Martin mentioning an approach where some concurrency
could be added without too much work. In my opinion, that should be a
priority for the release after 2.8.0. It would also be a good way of
showing that we're not just talk when it comes to concurrency
support. ;)

Best,
Ismael