[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Problem with sharing launch attributes
|
> I think we should just implement in CDI-GDB same
> functionality for core file (take if not null and prompt if null).
CDI-GDB kind of does this already. The problem is that there is no
text box to enter the core file. So, if DSF-GDB sets an invalid value
and we move the launch to a CDI-GDB one, there is no way to modify this.
But maybe you are suggesting to add a text box to the CDI-GDB launch?
>
> Marc Khouzam wrote:
> > Hi,
> >
> > the new launch system that handles both CDI-GDB and DSG-GDB
> brings up an
> > interesting
> > situation. Basically, a launch can be converted from
> CDI-GDB to DSF-GDB
> > and vice-versa.
> > This can cause a problem because the two types of launches
> share launch
> > attributes, but
> > don't always use them in the same way.
> >
> > For example, for the PostMortem launch, DSF-GDB sets
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH so as
> to remember
> > the core file
> > between launches. This is incompatible with CDI-GDB which
> requires that
> > attribute
> > to be null. I opened
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=273833
> > about this.
> >
> > I have two questions:
> >
> > 1- Is there some platform support in the launch
> infrastructure to allow
> > for a
> > 'transformation' that I could provide? Something that
> would run when a
> > launch
> > is converted one type to another. In that code, I could null
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH, when going to a
> > CDI-GDB launch.
> > I think this is the best solution, because this problem
> could arise for
> > any attribute
> > that is shared.
> >
> > 2- Is there a reason for the 'trick' used by CDI-GDB in its use of
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH?
> > Basically, the launch reads this attribute, if it null it
> prompts for a
> > core file,
> > then sets the attributes, then triggers a *new* launch, and finally
> > resets the
> > attribute to null.
> > I was thinking that we could simply always prompts and
> thus, not require
> > the
> > attribute to be null. But I don't know if there is reason
> for CDI-GDB to
> >
> > base itself on the attribute being null or not to trigger the prompt
> > (maybe to
> > allow for automated testing, or some manual debugging?)
> >
> > Thanks
> >
> > Marc
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>