| RE: [cdt-dev] [Launch] Why do CDT launch configs map the project? |
Hi, John,
You're probably right, that JDT had the refactoring, before 3.2. At least, with the refactoring solution, we can be more proactive and handle a variety of attributes:
- project name
- program/executable (probably not interesting, as it is a derived resource and would deleted
and re-created with a new name, not renamed)
- build configuration
Refactoring will easily handle deletion and renaming of projects. The latter two attributes don't affect the accessibility of the launch config (by filtering it out of the dialog, although that filter is optional).
Possibly it would be worthwhile implementing build configuration rename as a refactoring if there are other components/applications that reference configurations by name. I think the build config is referenced by ID, anyway, which protects the launch from renames.
It won't be much work to put together a patch and bugzilla it, then we can all have a look at something concrete.
The advantage of the resource mapping is that we do get optional filtering in the launch dialog (which is optional), including filtering by working set.
Perhaps the thing to do is just an enhancement to support refactoring but to leave the mapping as it is. It would still be nice for users to see, in the refactoring preview, which launch configs will be updated. In the case of deletion, the user could opt out of the launch config deletion (by unchecking the change in the preview) to preserve it for reconstitution of the project (e.g., by importing) but then would be defeated by the resource mapping forcibly deleting it anyhow.
Oh, if only the platform didn't delete the configs, but just let them be filtered...
cW
On Thu, 2009-04-23 at 10:49 -0500, John Cortell wrote:
I would guess that the JDT solution was in place before mapped resources, or that they have requirements above and beyond what the mapped resources can provide. We're sort of in the same boat since we put the project reference as an explicit CDT attribute in the launch config. We also now do the same for the build configuration. If the user renames the build configuration, we have a similar dilemma. I'm not aware of the capabilities and limitations of a refactoring mechanism. If it could be used to handle all the launch config updating that needs to be done when a user changes something in a project (including deleting the project), then it sounds like a promising idea.
John
-----8<-----
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
Christian W. Damus Software Developer, IDE Team QNX Software Systems |