|
Hi again,
Here's a follow-up question. If I have multiple launch targets (of the same type, but different names/ids), when I launch on one of them, my launch configuration provides is invoked to populate the launch configuration. However, when I later change launch targets,
the old launch configuration is cached and reused, and my launch configuration provider doesn't get the chance to update the launch configuration to reflect that it is being launched on a new target.
ProjectLaunchConfigProvider seems to cache created launch configurations, and only delegates to populateLaunchConfiguration() when the launch configuration is created. Is that by design? How are subclasses of ProjectLaunchConfigProvider expected to get notified
when the current launch target changes?
The project launch config provider is a delinquent case. There should be a launch config provider per target type. The supports() call determines which one is applicable. See the CoreBuildLocalLaunchConfigProvider. It makes sure the target is the local
target type. I have QNX providers that check for our QNX target types.
That said, you could have the same target type and have the supports() call check for other things. Whatever makes most sense for you.
/Jesper
Ok, so now I know a little so I can formulate my question a little clearer.
What I was wondering was if I need to create multiple target *types*, or if it works to create multiple ILaunchTarget objects having the same "type id", but different id:s. As far as I can tell it works fine to create multple targets of the same type, but
having different id:s.
I got confused by the fact that the launch target code sometimes refers to the id as the "user consumable name", leading me to think that the name was purely a presentation thing and not an ID, but the name of the target seems to actually be the id. Maybe
this code was written before there were any label providers controlling the presentation of a target?
/Jesper
Hi,
I'm trying to add support for the launchbar in our toolchain and have a question about how launch targets work.
We have our own debugger infrastructure (i.e. not gdb), which supports a number of so-called debugger drivers. A debugger driver in this context can something like our built-in simulator, or some form of external probe connected via USB (e.g. J-LINK). The
debugger driver is specified as a parameter to our external debugger, and I was planning to let a launch-target map to a debugger driver, since it becomes natural to think of a launch as "debug project X on J-LINK".
So, my question is, do I create one launch target type per driver, or do I let my implementation of ILaunchTargetProvider create multiple ILaunchTargets having the same ID? I guess another way to put it is: "is each
launch target expected to have a unique ID?"
Yes, the launch targets need unique IDs. We use them to know which target is active on startup. And I think I missed the point why you would multiple targets to have the same id.
Anything can be a target. For a given thing you are launching and a given launch mode, if the user has a choice of what else to use to launch, then it should probably be a separate target for each choice so they show up in the target selector and the user
can choose between them.
Of course, that leads to the case where a given device might have multiple paths, which is probably wise not to think of those devices as targets, but each of those paths are a target. Which probably means target is the wrong term to use, but couldn’t
think of a better one, though “connection” was once a term I used.
HTH,
Doug.
I hope I'm making myself clear here.
/Jesper
|
