Community
Participate
Working Groups
1. Start a new project. 2. Right click your project, click Import->Filesystem 3. Import the .h and .cpp files for your project 4. Click OK 5. Watch the CDT try to build your project without you having set any compiler or linker flags yet. I don't know of any other C++ IDE that tries to build your files as soon as you import them. Seeing as this is highly likely to fail, it should be disabled.
This setting is provided by the Eclipse platform.
I know that from using Eclipse for Java coding. It's still a bad idea to have on for C++ since it will fail for any nontrivial project. Combined with the CDT immediately starting indexing, it makes the CDT freeze for five minutes on my P3 700mhz laptop because the whole system is brought to its knees when files are first imported. Wherever the option comes from, I think CDT should override it to be off by default.
That may be a bad default for CDT, but is a perfectly reasonable default for other language tools. We won't be changing the default at the platform level. However, there are many options available for changing this default. Products can alter this in their plugin_customization.ini, and there is API to change this programmatically (IWorkspaceDescription.setAutoBuilding(...)). One option is to prompt the user when the first CDT project is created to ask if they want to turn off autobuild, or incorporate that option into the CDT project wizard. Finally, the CDT builder itself can be configured to not respond to auto-build events. I added this support specifically for CDT early last year, so it's disappointing that it has not been adopted (see bug 60803). Moving back to CDT for consideration of these options.
We do have an option to ignore auto-build. My understanding though is that the first build of an imported project will come in as a full build. Also, when auto build is turned on, there is no way to invoke a manual build (from what I can see). Someone else was looking at this issue back then so I'm not sure if we just plain missed something. But I didn't know that there was an API to change the setting. Putting this in the CDT's new project wizard makes a lot of sense. And something we should do for CDT 4.0.
From bug 60803, it looks like Dave Daoust was looking into this. When a builder is configured to not respond to autobuild, then the manual build commands are automatically enabled in the UI (see bug 60803 comment 22). If you don't see this happening, or have any other problems using this approach, don't hesitate to enter a bug report against platform UI and CC me.
In CDT you can configure (per project) it to ignore the autobuild event. (this is the default for Standard make projects). If the autobuild event is ignored, the manual build menu items appear. In Managed make projects, you cannot configure the response to the autobuild event . In this type of project the manual build menu items are disabled...
That must be what I'm seeing then. Moving to cdt-build for our managed build experts to consider options.
Putting it in the new project wizard sounds like a great idea :) (especially if the new project wizard is going to ask users if they want to import existing files) Now I'm a little bit confused about why choosing a managed make build would disable the ability to perform manual builds. Managed make versus Standard make, when I choose it in the wizard, says, "Do I want Eclipse to write my makefile for me or am I going to do it myself?" It shouldn't carry any commitment that I now have to rely on eclipse deciding when to build for me @_@
This bug seems to be related with the bug#87971 and could actually be marked as the dup of that bug. The problem is that we still haven't implemented the per-project autobuild enable/disable support for the Managed Make. I'll mark this bug as dependent on the bug#87971. I can not say for now whether or not I will have time to fix this for the 3.1.1, but, according to the New Project Model (bug #bug#115935), it is proposed to have one consistent CDT Build System that would incorporate both Standard and Managed make. If we all agree on this, I could fix this bug while adjusting the Standard and Managed make to the new project model (i.e. incorporating them to one Build System). Mikhail
Looks like the default on a per project basis was implemented for CDT 4.0. That's good. My one concern is that the "Build Automatically" menu item is in effect useless to a CDT project user, yet it is still available and looks usable. I don't have a good suggestion of what to do here. As was mentioned in the thread before, this makes sense for non-CDT projects. Would do you guys think about requesting that the platform remove this option from the menu in the future and also move this into the project options. It could be on by default for the Java projects, for example. Thanks, Ewa.
I think there's one more issue to resolve. When you do a Clean and Build Automatically is on, it'll kick off a build right away. There maybe something we can do in the CDT settings to stop that, if in fact we do want to stop it. I'm not sure. If we get that fixed, then I agree, the platform should leave build automatically on all the time, and let the projects decide how automatically they want it.
Ok, I see. My confusion as a user was in response to the fact that "Build Automatically" is enabled but "Build on resource save (Auto build)" is disabled by default in the CDT project properties. As a result the build is not triggered on resource save which is a change in behaviour from the last realease. This seems fine after getting used to it. Thanks, Ewa. (In reply to comment #11) > I think there's one more issue to resolve. When you do a Clean and Build > Automatically is on, it'll kick off a build right away. There maybe something > we can do in the CDT settings to stop that, if in fact we do want to stop it. > I'm not sure. > > If we get that fixed, then I agree, the platform should leave build > automatically on all the time, and let the projects decide how automatically > they want it. >
The way it works now is completely unintuitive. I love leaving build automatically turned on and yet there is very little documentation on how to turn it on, and going to project->build automatically, checking it, and it still not to work, makes the behavior completely buggy from an outside perspective. If anything build automatically should be a per project setting, or a per app setting but not both and at the very least better documented. This took way too long to figure out and only by going to this bugzilla was I able to find info about it. The current behavior is at best convoluted and practically broken.
My intuition would suggest: Case A: 1. Default preference when Eclipse starts up: Window > Preferences > General > Workspace > "Build Automatically" check-box 2. Session preference (defaults to 1) Project > Build Automatically 3. Project setting (defaults to 2; overrides preferences) Project Properties > C/C++ Build > Behavior Tab > "Build on resource save" check-box I would support "Putting it [Build on resource save] in the new project wizard sounds like a great idea". In Eclipse-3.3.1.1/CDT-4.0.2, 1 and 2 default to "true" and 3 defaults to "false" and the relationship between these settings is non-existent or not apparent. This is irritating for many small projects, requiring the user to dig into Project Properties for every new project. However, users who are working with large projects can set "Build Automatically" to "false" in 1 (Windows > Preferences).
I don't think this is likely to change. My $0.02 is that it's confusing to even present the choice to users, so if you put it in the New C/C++ Project Wizard, they are likely to turn it on thinking that it has something to do with a managed project vs. makefile project. Then they'll complain about how they have to wait for their application to link every time they hit the save button. The overwhelming majority of users don't want auto-build on for any project that uses an external compiler. I'm inclined to mark this WONTFIX unless one of the committers strenuously objects.
(In reply to comment #15) > I'm inclined to mark this WONTFIX unless one of the committers strenuously > objects. I did a bit of investigatory work in 6 towards locking only the output directories when the build is taking place. This basically fixes the interactivity problems for users trying to save an editor. However there are issues still outstanding with how the platform copes with this, and how it reports deltas to the builder next time it runs. Certainly something I'm intending to look at again, but this bug seems to have drifted from the original: "Build automatically is a really bad default" given that we don't default to honouring auto-build afaik.
