<p dir="ltr"><br>
On Mar 14, 2014 9:23 PM, "Dmitri Gribenko" <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
><br>
> On Tue, Mar 11, 2014 at 1:22 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
> > On Tue, Mar 11, 2014 at 12:36 PM, Philipp Moeller <<a href="mailto:bootsarehax@gmail.com">bootsarehax@gmail.com</a>> wrote:<br>
> >> Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>><br>
> >> writes:<br>
> >><br>
> >>> On Mon, Mar 10, 2014 at 5:59 PM, Philipp Moeller <<a href="mailto:bootsarehax@gmail.com">bootsarehax@gmail.com</a>> wrote:<br>
> >>>> For a good application I would like to define a certain set of<br>
> >>>> milestones we want to achieve. If you have anything specific in mind,<br>
> >>>> please let me know.<br>
> >>><br>
> >>> Based on the discussion so far, I think this could be used as a draft plan:<br>
> >>><br>
> >>> - attaching comments to macros;<br>
> >>> - parsing the reference syntax (recognising that the text from here to<br>
> >>> there is a possible reference, which we will need to resolve).<br>
> >>> Implementing Comment AST representation for unresolved references.<br>
> >>> Designing and implementing the XML representation for unresolved<br>
> >>> references.<br>
> >>> - resolving links to decls within the TU.  The result should probably<br>
> >>> be a Decl* or a USR.  The USR should be available in the XML;<br>
><br>
> Hi Philipp,<br>
><br>
> I have discussed this proposal with Argyrios Kyrtzidis today, and we<br>
> agreed that it would be best to only include the above points plus the<br>
> following point<br>
><br>
> - defining exactly what kind of information should we retain while<br>
> indexing the translation unit in order to be able to resolve (yet<br>
> unknown set of) links against it.</p>
<p dir="ltr">This seems really important. Linking is one of the quirkiest areas of Doxygen and getting it really right would be great.</p>
<p dir="ltr">> ... as 'required' in the GSoC proposal, and the work related to DB<br>
> mentioned below should be 'opportunity'.<br>
><br>
> >>> - defining a schema for a DB to store information about possible link<br>
> >>> targets (declarations and macros);<br>
> >>> - populating DB with information from TUs in the project;<br>
> >>> - resolving links to decls cross-TU using the DB.  The result should<br>
> >>> be a USR, and maybe the source file name + source location.<br>
><br>
> About the indexing, Argyrios suggested that it would be best to<br>
> decouple the process into two steps:<br>
><br>
> - indexing info should be produced as a separate file on disk (lets<br>
> call the file foo.clangindex)<br>
> - the tool can consume *.clangindex files to populate the database.<br>
><br>
> This separation allows us in future to produce indexing information<br>
> during compilation as a sidecar file, so that if the user is building<br>
> the project anyway, we don't parse the for indexing and compilation<br>
> twice.</p>
<p dir="ltr">Interesting. Is there some other part of clang that uses such files? How would I know to which code base to attach them? Or do we leave setting this up to the user? Is there a preference for certain data formats in clang? </p>

<p dir="ltr">> What do you think?<br>
><br>
> Dmitri<br>
><br>
> --<br>
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br>
</p>