RE: [cdt-dev] Problem with sharing launch attributes

["Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>]

Hi,

I have updated
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=273833

with a patch to add a textbox to the CDI Postmortem launch.
This aligns the DSF-GDB and CDI-GDB postmortem launches.

Someone would need to review and test it, since I don't know
much about CDI.  My tests all passed.

Thanks

Marc


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
> Sent: Monday, April 27, 2009 10:09 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Problem with sharing launch attributes
> 
> That would be logical.
> 
> Marc Khouzam wrote:
> >> 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
> >>
> > _______________________________________________
> > 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
>