Bug 331085 - Standard Make Project Build locks project
Summary: Standard Make Project Build locks project
Status: RESOLVED DUPLICATE of bug 331187
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 7.0.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Chris Recoskie CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-25 02:46 EST by Marko Tomljenovic CLA
Modified: 2010-11-26 05:29 EST (History)
2 users (show)

See Also:


Attachments
Build is blocking File Save (11.71 KB, image/png)
2010-11-25 04:24 EST, Marko Tomljenovic CLA
no flags Details
Threaddump from JVisualVM during waiting for save (24.59 KB, application/octet-stream)
2010-11-25 04:32 EST, Marko Tomljenovic CLA
no flags Details
Threaddump from JVisualVM during waiting for save (26.19 KB, application/octet-stream)
2010-11-25 04:40 EST, Marko Tomljenovic CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marko Tomljenovic CLA 2010-11-25 02:46:40 EST
Build Identifier: CDT 7.0.1

We are running a command line based build using the CDT Standard Make Build. Our build runs for multiple minutes. During the build none of the project files can be saved. This is really annoying our users since they know which files have already been processed by the build and which should not be touched.
This also hinders us from using the Standard Make mechanism for running our builds.
My proposal is a checkbox in the Build Properties Page to enable/disable locking the project/workspace during running the command line.

Reproducible: Always

Steps to Reproduce:
1. Run a build for a project
2. During the build change one of the files of the project and try to save.
3. A dialog pops up and says that you have to wait for the build to be finished.
Comment 1 James Blackburn CLA 2010-11-25 03:16:42 EST
In 7.0 makefile make no longer locks the workspace. See: bug 289986

What build action are you using to start the build? Can you provide a VM backtrace while the build is in progress using jstack / jvisualvm:
http://wiki.eclipse.org/How_to_report_a_deadlock
Comment 2 Marko Tomljenovic CLA 2010-11-25 04:24:03 EST
Created attachment 183837 [details]
Build is blocking File Save

In this screenshot you can see that I cannot save a changed file while the build is running. I am calling a gnu make.exe.
Comment 3 James Blackburn CLA 2010-11-25 04:29:30 EST
Please provide a backtrace.
Comment 4 Marko Tomljenovic CLA 2010-11-25 04:32:07 EST
Created attachment 183838 [details]
Threaddump from JVisualVM during waiting for save
Comment 5 James Blackburn CLA 2010-11-25 04:35:27 EST
You must have just missed it -- there's neither a build nor save happening in that backtrace.

If you've caught it you should see the word 'build' in one of the threads.
Comment 6 Marko Tomljenovic CLA 2010-11-25 04:40:43 EST
Created attachment 183839 [details]
Threaddump from JVisualVM during waiting for save
Comment 7 James Blackburn CLA 2010-11-25 04:44:49 EST
Well there are a couple things here:
 1) You have Auto-build switched on. This runs with the WS scheduling rule (and is a platform issue).  You should probably disable auto-build and just schedule builds manually using the make targets view or ctrl-B or similar.
 2) The build is performing refresh after build. This still locks the resources being refreshed.
Comment 8 Marko Tomljenovic CLA 2010-11-25 04:53:31 EST
Hi
Thank you for the super fast response :)

The problem with your answers is:

1. I cannot disable autobuild since other parts of our application are depending on it.
2. The refresh after build is necessary since the build generates files that should be synced with the eclipse resource system. Is this an internal feature if an auto build is executed? Or is this done autom. when a file is being saved?

Now I have a different question:
What I exactly need is to run make targets that are not relying on the eclipse builder mechanism since all this auto build stuff cannot be used together with our build. What I tried is to create some custom make targets and to disable the "Workbench build behaviour" targets (C/C++ Build property page). This way the build runs not together with the other Eclipse builders. But now I cannot run my custom target anymore. Is this supposed to be like that?
Comment 9 James Blackburn CLA 2010-11-26 05:29:42 EST
Ok. I've filed Bug 331187 for auto-build holding the workspace root rule.
The refresh after build is covered by Bug 133881

(In reply to comment #8)
> 1. I cannot disable autobuild since other parts of our application are
> depending on it.

You can do this on the CDT Build command itself.
Project > Properties > Builders > CDT Builder > Edit ...
  Uncheck "During auto builds"

> 2. The refresh after build is necessary since the build generates files that
> should be synced with the eclipse resource system. Is this an internal feature
> if an auto build is executed? Or is this done autom. when a file is being
> saved?

The CDT builder is doing an explicit project refresh. This may take some time depending on the size of your project and the speed of your filesystem.  There are some thoughts on improving this: Bug 133881 and Bug 330360

> What I exactly need is to run make targets that are not relying on the eclipse
> builder mechanism since all this auto build stuff cannot be used together with
> our build. What I tried is to create some custom make targets and to disable
> the "Workbench build behaviour" targets (C/C++ Build property page). This way
> the build runs not together with the other Eclipse builders. But now I cannot
> run my custom target anymore. Is this supposed to be like that?

You can create make targets using the "Make Target" view, and double click on them.  Or configure a single build command on the C/C++ Build property page to run when you press ctrl-b (right click on Project > Build) or use the Project > menu to build projects.


I believe your issues are covered in these other bugs. Do ask the cdt-dev mailing list for other issues and advice.

*** This bug has been marked as a duplicate of bug 331187 ***