Re: [cdt-dev] Re: [cdt-patch] Scanner Interface for Managed and Standard

["Alain Magloire" <alain@xxxxxxx>]

> 
> This is a multipart message in MIME format.
> --=_alternative 00541D2485256D5C_=
> Content-Type: text/plain; charset="US-ASCII"
> 
> Thanks Sam,
> I think your suggestion has a lot of merit. When I was thinking about how 
> to add path and symbol information to the standard build, I decided to 
> concentrate build-specific information in the .cdtbuild file, leaving the 
> .cdtproject file for the QNX Descriptor manager mechanism. To me, that 

sigh ... it is not the "QNX Descriptor" it is a general purpose persistent
mechanism that Dave Inglis, provided for modules of the CDT, anybody can
use it to save information.  The rationale here is that lots of info
needs to be shared(via CVS or other mechanism) and persistency across session.

> meant storing the stop on error and make command setting, as well as the 
> path and symbol information since they are all build-related.

The "std make" builder decide not to save this, since it was consider a
"personnal" setting i.e. a setting that does not need to be shared between
user.  So the metadata of the project is fine(not sharable) for this type of info.

> The binary parser stuff is not really part of the build model, so I thought I would 
> leave it as a preference on the project.

Yes, the binary parser uses this mechanism to save its setting so they can be share.

> However, in the end, I decided 
> to only use the .cdtbuild file for the new information I was adding just 
> in case there were fielded products that had dependencies on the 
> .cdtproject file contents.

We made a proposal on this, explaining what the ".cdtproject" file is a general
purpose mechanism to save settings.  (See the proposal and API in cdt-home)
	cdt-home/docs/cdtproject_extensions.html

> In the end, the decision sort of felt like 
> debating how many angels  can dance on the head of a pin; I just wanted to 
> store the information, it didn't really matter where and it was annoying 
> to have to think about it.
> 


If you feel more comfortable and things are easier, by providing your own
way of saving the settings ... that's fine.  But in the end, this is a cooperation
effort and we will have to find away to make all this work and stop the duplication.
But that's ok, working with other people's code is never easy, and it takes
a few iterations to get things right 8-),

> If we do decide to use one file, we should create something like the 
> extension point mechanism; the file would contain named subsection that 
> you could create and read from as you needed to. Only your named section 
> would be read and stored to when you opened or saved the information; the 
> mechanism would ignore every other section in the file. An extension point 
> could be used to register named sections to avoid naming conflicts. 
> 
> We should also bear in mind that these dot-project files are really for 
> storing settings that are not user-specific or that you want to be able to 
> share between team members. You can always use the properties mechanism to 
> persist user-specific information from one session to the next.
> 

... Please read the proposal.
Although Dave is on vacation, I'm sure he's open to tweaks/twists and even rewrite
so we can all reach a consensus.