Community
Participate
Working Groups
I have a complex multi-project Makefile-based source tree with a lot of shared code and am at a loss for how to set up Eclipse to let me build & debug them. My latest attempt of using a single project and different configurations for all my targets looked promising, until I realized that the new C/C++-specific references don't support multiple references to different configurations in the same project.
We need this as well. The core API only supports referencing an individual project->configuration (uses a map). We should enhance this API to allow referencing multiple configurations.
The patch on Bug 331031 contains this functionality.
(In reply to comment #2) > The patch on Bug 331031 contains this functionality. James, bug 331031 doesn't touch RefsTab.java, and thus the user cannot select more than one build configuration in the GUI. Did you mean that your solution provides the needed infrastructure but doesn't actually make the corresponding UI changes? If so, I'll close the gap. I just want to make sure I'm not missing something.
I think the Ui change was contained in the patch for this bug: https://github.com/jamesblackburn/cdt/tree/bug/317229_multiple_refs That said I seem to remember the RefsTab could use some love...
(In reply to comment #4) > I think the Ui change was contained in the patch for this bug: > https://github.com/jamesblackburn/cdt/tree/bug/317229_multiple_refs > That said I seem to remember the RefsTab could use some love... Hm. So that patch (branch) touches a lot of the same files as the 331031 solution, and the changes *appear* similar on the surface. I'd like to avoid trying to reconcile the two. Can you tell me if I can just ignore files in 317229 that are also in 331031. I have 331031 already merged.
(In reply to comment #4) > I think the Ui change was contained in the patch for this bug: > https://github.com/jamesblackburn/cdt/tree/bug/317229_multiple_refs > That said I seem to remember the RefsTab could use some love... Not sure about love, but I do need to question why the implementation in this patch overhauled the tab to use a table widget (see attachment) instead of just keeping the existing checked tree widget and allowing more than one configuration to be checked for a given project. I'm not sure I like the table UI for this, and I have to think it was a usability preference rather than a necessity for supporting this feature (multiple config references). The table UI makes for a cumbersome workflow. Adding a reference requires opening a dialog to accomplish exactly the same steps that could be done in the tab itself. Deleting a configuration requires not only checking a reference but then hitting a Delete button. The only downside I see for the existing checked tree UI is that the tab must list all the projects in the workspace, whether or not the projects are referenced. I suppose if you have dozens of projects, this could be seen as unnecessary clutter. Weighing the pros and cons, I think the checked-tree UI comes up on top. So, I plan to not take that part of this contribution. And as the rest of the contribution seems to be in bug 331031, I think I'll probably be passing on this patch entirely. I will leave the UI as is and simply allow multiple configurations in a project to be checked. If someone feels strongly about changing the UI to a table, he/she is certainly welcomed to try rallying support for it on the cdt dev list.
Created attachment 217830 [details] overhauled references tab UI provided by this patch
(In reply to comment #5) > Can you tell me if I can just ignore files in > 317229 that are also in 331031. I have 331031 already merged. Sorry for the delay. I'm afraid I don't remember the context. I thought I had an uber branch with everything merged together, but can't find it on the github repo. (In reply to comment #6) Decent analysis. Will try to respond to the points. > The table > UI makes for a cumbersome workflow. Adding a reference requires opening a > dialog to accomplish exactly the same steps that could be done in the tab > itself. Agreed. This is a UI usability issue, it was written quite quickly by a summer student. I thought it would ideally work like the debug Expressions view allowing in-place editing of the tabular contents - addition+deletion and in-place re-ordering. > Deleting a configuration requires not only checking a reference but > then hitting a Delete button. As above. > The only downside I see for the existing checked > tree UI is that the tab must list all the projects in the workspace, whether or > not the projects are referenced. I suppose if you have dozens of projects, this > could be seen as unnecessary clutter. This is one reason: we had >100 library projects, each with a handful of build configurations. The references tab with check boxes was very cumbersome. The main issue, though, was one of ordering. With project references, exported settings: include paths and include files as well as preproc defines are propagated down to the referencing project. This means that a library can export its include path once and have its headers automatically available to all downstream referencing projects. In the case of include paths, header file resolution order is key. The UI really needs to provide a way to order the build config references, and I don't think that the existing UI does? > Weighing the pros and cons, I think the checked-tree UI comes up on top. So, I > plan to not take that part of this contribution. And as the rest of the > contribution seems to be in bug 331031, I think I'll probably be passing on > this patch entirely. OK. From the core API POV, they key bit was the ICConfigDesc change get/setReferenceEntries. I believe this copes with multiple build configs from the same project correctly.
(In reply to comment #8) > The main issue, though, was one of ordering. With project references, exported > settings: include paths and include files as well as preproc defines are > propagated down to the referencing project. This means that a library can > export its include path once and have its headers automatically available to > all downstream referencing projects. > In the case of include paths, header file resolution order is key. The UI > really needs to provide a way to order the build config references, and I don't > think that the existing UI does? Ah. I wasn't aware of that. Is that stock CDT behavior[1]? If so, then indeed ordering is something that we need to give the user control of. That should be doable via the checked-tree UI, so I'll plan on doing it that way. [1] I was unsuccessful in finding out through experimentation with Juno. Made one simple project dependent on another and am getting build errors (where there are none if there are no dependencies) Need to investigate.
> Ah. I wasn't aware of that. Is that stock CDT behavior[1]? If so, then indeed > ordering is something that we need to give the user control of. That should be > doable via the checked-tree UI, so I'll plan on doing it that way. Hm. I see that this is theoretically not possible to the same extent as with the table UI. With a table, you can interlace the ordering with configurations from different projects: E.g: proj1/conf1 proj2/conf1 proj1/conf2 With the tree UI, I could allow the user to set the order of the configurations within a project, but could not support this sort of interlacing. However, this scenario sounds academic to me. Was this a real-world need for Broadcomm?
(In reply to comment #9) > Ah. I wasn't aware of that. Is that stock CDT behavior[1]? If so, then indeed > ordering is something that we need to give the user control of. That should be > doable via the checked-tree UI, so I'll plan on doing it that way. Should be, but it's somewhat hidden in the default release: http://stackoverflow.com/questions/1790631/export-button-in-eclipse-cdt-paths-and-symbols-dialog
(In reply to comment #10) > However, this scenario sounds academic to me. Was this a real-world need for > Broadcomm? I can't think of case where that might happen. I think it's fine to go with the minimum UI change at the outset.
(In reply to comment #12) > (In reply to comment #10) > > However, this scenario sounds academic to me. Was this a real-world need for > > Broadcomm? > > I can't think of case where that might happen. I think it's fine to go with > the minimum UI change at the outset. Excellent. Thanks for your help. I think I have everything I need now to wrap this up. Good hearing from you, btw. Your input and contributions are much missed.
