ceylon-ide-eclipse icon indicating copy to clipboard operation
ceylon-ide-eclipse copied to clipboard

delay binary build until Run/Debug

Open gavinking opened this issue 10 years ago • 5 comments

I just discovered something very useful: if you turn off "Compile project for JVM" in the SDK project, everything in the IDE still works, except for Run/Debug, but clean builds are 2-3 times faster. This makes developing the SDK much more pleasant!

This makes me think we should either:

  • add an option to make Ceylon IDE behave more like IntelliJ, that is, wait until Run is called to do the build (we would have to track what files had not been fully built, I suppose, but this is perhaps not so hard), or
  • perhaps, always perform binary builds asynchronously in a very low-priority background thread, and make Run/Debug wait for any active binary build to finish.

WDYT, @davidfestal?

gavinking avatar Aug 06 '14 21:08 gavinking

It seems this works for the SDK because :

  • It doesn't contain Java classes that use the Ceylon code (full bidirectional Java interop)
  • It doesn't depend on another Ceylon project.

But for those 2 points, it is necessary to have binaries in order to avoid errors to occur. This is related to the fact that now we load model elements from binaries (which was clearly an optimization for full build and binary generation). Of course, if you disable "Compile project for JVM", you also disable the loading of the Ceyon model from binaries, and come back to using only sources archives. But avoiding generating binaries regularly though using the "load model from binaries" mode will necessarily produce model inconsistencies that would lead to unexpected behaviors or errors in case you use either full bidirectional Java interop or cross-project dependencies.

IMO when #843 is implemented (as well as incremental build also for module/package descriptor changes) we will nearly never need running a clean build. I'd like to start #843 very soon.

davidfestal avatar Aug 07 '14 08:08 davidfestal

  • It doesn't contain Java classes that use the Ceylon code (full bidirectional Java interop)

Which is the same restriction the CLI compiler currently has, so this does not sound like it is important (for now).

  • It doesn't depend on another Ceylon project.

Since we still know how to load models from sources, and since we have source for any Ceylon project, I don't see why this restriction couldn't be removed.

IMO when #843 is implemented (as well as incremental build also for module/package descriptor changes) we will nearly never need running a clean build.

I have no clue what #843 is about.

gavinking avatar Aug 07 '14 08:08 gavinking

  • It doesn't depend on another Ceylon project.

Since we still know how to load models from sources, and since we have source for any Ceylon project, I don't see why this restriction couldn't be removed.

Indeed, it looks like this restriction could be easily removed by having the build process generate a .src archive when both JS and Java compilation is disabled. Actually that looks like an independently useful thing to be able to do!

gavinking avatar Aug 07 '14 08:08 gavinking

By the way, the CLI compiler also supports full bidirectional interop (Java classes that use Ceylon definitions). I've just tested it. So the new option proposed in this issue would introduce a limitation that the CLI compiler doesn't have.

davidfestal avatar Aug 27 '14 11:08 davidfestal

for 1.2 if we still feel it as necessary

davidfestal avatar Aug 27 '14 19:08 davidfestal