Why is compile / build a blocking background job?

Hi Stefan,

Build operation is the eclipse behavior. As build operation modify the Eclipse file system (resources), it is dangerous to run other tasks that could read the file system.

Regards,

DivyaTheja

Thanks for the reply.

Maybe my confusion is in when is it a build and when is it a compile? A build seems to sometimes trigger a compile, a compile does not trigger a build.

14941 wrote:
Thanks for the reply.
Maybe my confusion is in when is it a build and when is it a compile? A build seems to sometimes trigger a compile, a compile does not trigger a build.

The 'build' is indeed an Eclipse thing, multiple builders can be registered for a project (given it's nature) and will be triggered automatically by Eclipse (incremental) or by user actions (clean/full). The OE contributed builder will compile every file that need to be build, only changed files for incremental or all files in the project for full build... this is done in the background but still it can block some user operations, in this case the compile action does require access to the project AVM which is busy with the full build. For instance, if you try to launch a run configuration (and don't use project AVM for it) it should spawn a new process and don't block on the build.

A 'compile' is just a contributed action for the navigator or context menu in the editor, most probably it does not use the Eclipse build system although I do not know how it's actually implemented

Thanks for the info.

So when you build a project, it is titled 'Building workspace' with subtitle 'Compiling' and when you compile a project it is titled 'Compile files' with subtitle 'Building...: Compiling' - I'm still trying to wrap this terminolgy into your explanation ;-)

can only tell you how it's done in zamolxis, eventually the same build mechanism can be (re) used and that will explain the message mix... someone from pdsoe dev-team will be able to explain it better though.

The "building workspace" in eclipse includes all the builders for a project. Its a single job managed by eclipse and runs each builder in order passing the changed list of files to each.  The "compiling..." message which is used when you explicitly invoke the compiler from the menu only compiles ABL code, it doesn't run the other builders for the project.  Its much the same code, but not exactly.  There are a some subtle differences that usually won't matter.  The builder will skip already compiled stuff since its incremental and works off the change list provided by eclipse, but if you compile an individual file, it "forces" the compile even if all the include files are up to date, but will compile everything that is selected including following into child directories.

There are many operations in eclipse that "lock" a section of the workspace, or the whole thing.  A "build" operation locks everything, The build manager in eclipse does this, PDS has no control over it.  The build manager doesn't know what the builders are actually going to do, but it gives them free reign to do it within the lock.

The compile job tries to be a litter smarter and only locks the resources it needs to operate on.  But ANY file/directory lock will block workspace lock so the two types of jobs are mutually exclusive.

Generally you should turn off the builder and only use the explicit compiler, or vice-versa, but sometimes having both is needed for various reasons.

Great explanation!

but sometimes having both is needed for various reasons

Any chance to get more details on this?

I don't have a specific use case.  Its there because sometimes you want to force a compile on something.  Maybe you changed an include file outside eclipse, or maybe ...whatever you can think of.  Its useful.

I turn off the automatic Builder functionality usually, but use the Build functionality manually.

I have multiple projects in a workspace, typically with lots of OOABL in each. There are dependencies between the projects, which I set up in the Build Order preference screen of Eclipse. So when I Build All, the projects are built in the correct order. This is necessary when project B implements an interface from project C, so I need project C to build first before I can build project B. The default order is alphabetic.

This is largely a workaround for PDSOE's lack of knowledge of class interdependencies. The approach is a little hinky too, because it's workspace dependent. I've been thinking of using PCT/Ant to keep this information within the projects themselves. Any opinions?

-- peter