Bugzilla – Full Text Bug Listing
| Summary: | Two project reference dialogs are confusing; unify CDT references with Platform references | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Dallaway <john> |
| Component: | cdt-build | Assignee: | cdt-build-inbox <cdt-build-inbox> |
| Status: | ASSIGNED --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonel.pazargic, bbelyavsky, cdtdoug, elaskavaia.cdt, eostroukhov, jamesblackburn+eclipse, yevshif |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 309769 | ||
|
Description
John Dallaway
Use CDT reference between project configurations -- the references you refer to are at the platform level and don't express the dependency between CDT build configurations. Properties > C/C++ General > Paths & Symbols > References: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.user/reference/cdt_u_prop_general_pns_ref.htm (In reply to comment #1) > Use CDT reference between project configurations -- the references you refer to > are at the platform level and don't express the dependency between CDT build > configurations. From a usability perspective, the ignoring of platform-level project references will be a source of confusion and may introduce subtle build problems when upgrading to CDT 7.0. I would expect the common platform-level project references UI to be functional across all project natures, working in addition to (or co-operating with) any more advanced nature-specific settings. If the user-specified platform-level project references are being ignored and the consensus is that this is OK, then the CDT user documentation should be modified to make this clear. Ref: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-doc/org.eclipse.cdt.doc.user/reference/cdt_u_prop_ref.htm?root=Tools_Project&view=co&pathrev=CDT_7_0_0 Should I re-open the bug as a cdt-doc bug? Ok, I agree that having two property pages for this is confusing; we need a better way of representing this in the UI to the user. I don't believe this is a regression from CDT 6, as the previous behaviour involved the platform's build action building an arbitrary configuration in the referenced project, followed by the correct (CDT referenced) configuration. References were built multiple times... The issue is that the platform has no way of representing a more flexible CDT-style configuration dependency. In fact its UI code that currently builds referenced projects (rather than an intrinsic part of the core.resources build). In 7 the platform references follow CDT config references, but not vice-versa. The CDT build action builds based on configuration references, but could be expanded to build the active config of an eclipse referenced project -- if there's more than one configuration this would be arbitrary... Ideally we shouldn't have two ways of representing this, as its confusing, so I've updated the summary to reflect this... (In reply to comment #3) > Ok, I agree that having two property pages for this is confusing; we need a > better way of representing this in the UI to the user. James, it seems that the changes in behaviour between CDT 6 and CDT 7 reach further that I thought: With CDT 6, when I invoke "Clean Project", any referenced projects are also cleaned. With CDT 7, this does not happen. Not a big problem, but a departure from expected behaviour. More significantly, with CDT 6, when I build a project, _all_ the builders associated with any referenced projects are invoked (not just the "CDT Builder"). With CDT 7, it appears that only the CDT Builder is invoked for the referenced projects. Some of my projects will therefore no longer build correctly when built indirectly (as a referenced project) because the CDT Builder requires a source file which is generated by a preceding builder in the ordered list of builders for the project. Can you confirm that I have interpreted the CDT 7 behaviour correctly? If so, I think this is more than just a UI issue. (In reply to comment #4) > With CDT 6, when I invoke "Clean Project", any referenced projects are also > cleaned. With CDT 7, this does not happen. Not a big problem, but a departure > from expected behaviour. I don't believe we've changed the behaviour of clean. I could be wrong though... > More significantly, with CDT 6, when I build a project, _all_ the builders > associated with any referenced projects are invoked (not just the "CDT > Builder"). With CDT 7, it appears that only the CDT Builder is invoked for the > referenced projects. Some of my projects will therefore no longer build > correctly when built indirectly (as a referenced project) because the CDT > Builder requires a source file which is generated by a preceding builder in the > ordered list of builders for the project. This does sound like a regression. The issue is that previously: - UI code called build on all referenced projects, before calling build on the top-level project - CDT Builder actually runs make directly in the referenced projects, without going through core.resources IProject.build. Together this results in projects being built more than once, and the CDT builder behaviour causes problems: with build delta, pre-build/post-build event flow, resource locking, etc. The root of the problem is the way the cdt builder implicitly builds references (because the platform doesn't give any context on what's being built...). We should fix this for 7.0.1. It would be quicker if you could contribute a patch? Actually "clean" behavior as it is now is more adequate. When I build a project I do want to rebuild "references" projects. But if I clean my project I don't want references project to be cleaned. I may want to clean project referencing mine, but it is different story. So whoever fixing this I think clean works correctly now. (In reply to comment #6) > Actually "clean" behavior as it is now is more adequate. When I build a project > I do want to rebuild "references" projects. But if I clean my project I don't > want > references project to be cleaned. I may want to clean project referencing mine, > but it is different story. So whoever fixing this I think clean works correctly > now. Actually, when I run clean, I don't want it to clean other projects. Why would you want to clean other projects that you haven't selected? Thanks to make's dependency checking, after the clean, the necessary bits are going to be rebuilt anyway. I'll raise a separate bug on that topic if there already isn't one. Clean works as you both expect, afaik :) We don't clean references when cleaning the top-level project, and this behaviour hasn't changed... (In reply to comment #8) > Clean works as you both expect, afaik :) > We don't clean references when cleaning the top-level project, and this > behaviour hasn't changed... I'm using project references (haven't discovered the "other" references yet) and, yes, cleaning the top-level project that depends on library projects cleans those library projects. Sucks. And then proceeds to do a build that I don't want it to. Anyway, clean is for another bug. (In reply to comment #5) > > More significantly, with CDT 6, when I build a project, _all_ the builders > > associated with any referenced projects are invoked (not just the "CDT > > Builder"). With CDT 7, it appears that only the CDT Builder is invoked for > > the referenced projects. Some of my projects will therefore no longer build > > correctly when built indirectly (as a referenced project) because the CDT > > Builder requires a source file which is generated by a preceding builder in > > the ordered list of builders for the project. > > This does sound like a regression. The issue is that previously: > - UI code called build on all referenced projects, before calling build on > the top-level project > - CDT Builder actually runs make directly in the referenced projects, > without going through core.resources IProject.build. > > Together this results in projects being built more than once, and the CDT > builder behaviour causes problems: with build delta, pre-build/post-build > event flow, resource locking, etc. > > The root of the problem is the way the cdt builder implicitly builds > references (because the platform doesn't give any context on what's being > built...). We should fix this for 7.0.1. It would be quicker if you could > contribute a patch? I will take a look. I have raised bug 317402 to keep the build behaviour issue separate from the UI issue. (In reply to comment #9) > I'm using project references (haven't discovered the "other" references yet) > and, yes, cleaning the top-level project that depends on library projects > cleans those library projects. Sucks. I believe this is dependent on how you fire off the build. Before applying the patch for bug 317402 I couldn't reproduce this, as the CDTBuildAction shouldn't build references of CDT projects (clean or incremental). It checks CCorePlugin.getDefault().isNewStyleProject((IProject)res) were you definitely invoking the clean in the cdt perspective on new-style cdt projects? By default the platform cleans references too (BuildAction.java doesn't consider the build kind...). If you put a breakpoint in CommonBuilder#clean() it would be interesting to get a brack-trace on which action is firing the clean. Unfortunately the change I just committed in bug 317402 will cause references to always be cleaned. Do file a bug as we can stop this from happening (or at least make it configurable) for our build action. > And then proceeds to do a build that I > don't want it to. No doubt you have workspace auto-build on. The cdt builder is configured to ignore auto build (by default). Unfortunately the platform incorrectly promotes auto-build after a clean to a full build :(. There's a fix on bug 306746 which is waiting platform review. (In reply to comment #3) > Ok, I agree that having two property pages for this is confusing; we need a > better way of representing this in the UI to the user. It should be possible to present CDT references as a sub-page under platform "Project References" property page. At least this way it would be easier to discover. |