[cfe-dev] Question of compile class

Nikola Smiljanic popizdeh at gmail.com
Thu Nov 6 14:55:26 PST 2014


How will it waste time if you don't change it?

On Fri, Nov 7, 2014 at 9:53 AM, Xiaohui Chen <xchen422 at uwo.ca> wrote:

> I am writing a source to source tool which need to add some new keywords
> in the clang source file, so this tool can parse
> the input file with my new keywords, now this tool is still under
> developing and  debugging, each time when i want to
> recompile this tool  i do not want to involve llvm stuff, because it will
> waste some time......
>
>
> On 11/06/14, *Nikola Smiljanic * <popizdeh at gmail.com> wrote:
>
> Why exactly do you want an out of source build if your using makefiles?
> It's beneficial with Visual Studio but I don't see the reason for it if
> you're building from the command line?
>
> On Fri, Nov 7, 2014 at 9:14 AM, Xiaohui Chen <xchen422 at uwo.ca> wrote:
>
>> .... i have no idea of cmake ....
>>
>> i use makefile under linux, so who could help?
>>
>>
>> On 11/06/14, *Nikola Smiljanic * <popizdeh at gmail.com> wrote:
>>
>> I only know how to do this with cmake.
>>
>> On Fri, Nov 7, 2014 at 8:32 AM, Xiaohui Chen <xchen422 at uwo.ca> wrote:
>>
>>> i think i get your point and that is what i expect.
>>>
>>> you mean that:
>>>
>>> 1. make a standalone directory for Clang not in llvm/tools
>>>
>>> 2. compile both llvm and clang as usual
>>>
>>> 3. if i modify Clang source file, i just execute the Makefile inside
>>> clang/ directory, so it
>>> will just re-compile the Clang file  without checking llvm files
>>>
>>> is there any instructions to do this?
>>>
>>> Especially in step 2, if i compile in this way i guess i will break the
>>> dependence relationship in "configure" file?
>>>
>>> Best
>>> xiaohui
>>>
>>>
>>> On 11/06/14, *Nikola Smiljanic * <popizdeh at gmail.com> wrote:
>>>
>>> The best you can do is compile clang "out of source". Meaning the clang
>>> directory stands on its own and not in llvm/projects. This makes a
>>> difference if you're generating Visual Studio solution file as you won't
>>> have to load llvm projects. But llvm must be built.
>>>
>>> On Fri, Nov 7, 2014 at 4:24 AM, Jingyue Wu <jingyue at google.com> wrote:
>>>
>>>> I don't think so. clang uses a lot of LLVM's core libraries.
>>>>
>>>> Jingyue
>>>>
>>>> On Thu Nov 06 2014 at 9:14:49 AM Xiaohui Chen <xchen422 at uwo.ca> wrote:
>>>>
>>>>> Hi all:
>>>>>
>>>>> I am writing a source to source tool and adding new keywords in the
>>>>> clang source file(i just care about the AST),
>>>>> is there a way to just compile the clang frontend source file but not
>>>>> including llvm source file?
>>>>>
>>>>> Sincerely
>>>>> xiaohui
>>>>>
>>>>> On 11/03/14, *Nikola Smiljanic * <popizdeh at gmail.com> wrote:
>>>>>
>>>>> On Tue, Nov 4, 2014 at 7:14 AM, Xiaohui Chen <xchen422 at uwo.ca> wrote:
>>>>>
>>>>>> Thanks for your reply.
>>>>>>
>>>>>> I am confusing here:
>>>>>>
>>>>>> 1. Traverse method visits AST nodes that form a tree. CXXRecordDecl
>>>>>> is the parent of each of its CXXMethodDecls and FieldDecls.
>>>>>>
>>>>>>  CXXMethodDecls ( FieldDecls )  is not  a member of CXXRecordDecl and
>>>>>> also does not inherit from CXXRecordDecl, so how could
>>>>>> you define them as parent-child relationship?
>>>>>
>>>>>
>>>>> CXXRecordDecl contains CXXMethodDecls and RecordDecl contains
>>>>> FieldDecls. They're just stored in the DeclContext class but are exposed
>>>>> with method_begin/method_end and field_begin/field_end.
>>>>>
>>>>> 2. WalkUpFrom method visits the class hierarchy of a single AST node.
>>>>>> CXXRecordDecl inherits RecordDecl which inherits TagDecl etc.
>>>>>>
>>>>>> here TagDecl has three direct parents, so will WalkUpFrom be applied
>>>>>> to these three classes?
>>>>>>
>>>>>>
>>>>> TagDecl does have three super classes but only one of them is also an
>>>>> AST node. AST is built from declarations, statements and types. DeclContext
>>>>> represents a declaration context and structs/classes introduce one. They
>>>>> are also redeclarable (forward declaration) which is what Redeclarable
>>>>> class keeps track of.
>>>>>
>>>>>
>>>>> sincerely
>>>>>> xiaohui
>>>>>>
>>>>>>
>>>>>> On 11/03/14, *Nikola Smiljanic * <popizdeh at gmail.com> wrote:
>>>>>>
>>>>>> There are two parent-child relationships at play.
>>>>>>
>>>>>> 1. Traverse method visits AST nodes that form a tree. CXXRecordDecl
>>>>>> is the parent of each of its CXXMethodDecls and FieldDecls. This is what
>>>>>> you'll see with clang -cc1 -ast-dump
>>>>>> 2. WalkUpFrom method visits the class hierarchy of a single AST node.
>>>>>> CXXRecordDecl inherits RecordDecl which inherits TagDecl etc. Think of
>>>>>> serialization, to serialize CXXRecordDecl you'd first want to serialize
>>>>>> everything from the base class and so on recursively.
>>>>>>
>>>>>> On Mon, Nov 3, 2014 at 12:32 PM, Xiaohui Chen <xchen422 at uwo.ca>
>>>>>> wrote:
>>>>>>
>>>>>>>  Dear all:
>>>>>>>
>>>>>>> I am using Clang as the frontend of my project, but i am confusing
>>>>>>> of the following statements.
>>>>>>> PS: i am a newbie.
>>>>>>>
>>>>>>> These tasks are done by three groups of methods, respectively:00089 ///   1. TraverseDecl(Decl *x) does task #1.  It is the entry point00090 ///      for traversing an AST rooted at x.  This method simply00091 ///      dispatches (i.e. forwards) to TraverseFoo(Foo *x) where Foo00092 ///      is the dynamic type of *x, which calls WalkUpFromFoo(x) and00093 ///      then recursively visits the child nodes of x.00094 ///      TraverseStmt(Stmt *x) and TraverseType(QualType x) work00095 ///      similarly.00096 ///   2. WalkUpFromFoo(Foo *x) does task #2.  It does not try to visit00097 ///      any child node of x.  Instead, it first calls WalkUpFromBar(x)00098 ///      where Bar is the direct parent class of Foo (unless Foo has00099 ///      no parent), and then calls VisitFoo(x) (see the next list item).00100 ///   3. VisitFoo(Foo *x) does task #3.00101 ///00102 /// These three method groups are tiered (Traverse* > WalkUpFrom* >00103 /// Visit*).  A method (e.g. Traverse*) may call methods from the same00104 /// tier (e.g. other Traverse*) or one tier lower (e.g. WalkUpFrom*).00105 /// It may not call methods from a higher tier.
>>>>>>>
>>>>>>> According to the above statement, the calling relationship between
>>>>>>> these
>>>>>>> functions are organized in this way in general:
>>>>>>>
>>>>>>> Traversal*()
>>>>>>> {
>>>>>>>         .......
>>>>>>>         WalkUpFrom*();
>>>>>>>         .......
>>>>>>> }
>>>>>>>
>>>>>>> WalkUpFrom*()
>>>>>>> {
>>>>>>>          .......
>>>>>>>          Visit*();
>>>>>>>          .......
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> am i right?
>>>>>>>
>>>>>>> For this statement:
>>>>>>>
>>>>>>> 00096 ///   2. WalkUpFromFoo(Foo *x) does task #2.  It does not try to visit00097 ///      any child node of x.  Instead, it first calls WalkUpFromBar(x)00098 ///      where Bar is the direct parent class of Foo (unless Foo has00099 ///      no parent), and then calls VisitFoo(x) (see the next list item).
>>>>>>>
>>>>>>> what do you mean by saying "the direct parent class of Foo"?
>>>>>>> why i need to visit the parent class before i visit the current
>>>>>>> class?
>>>>>>> what is the purpose? Could you please give me a short example?
>>>>>>>
>>>>>>> Thank you in advance!
>>>>>>>
>>>>>>> Sincerely
>>>>>>> xiaohui
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>  _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141107/1581b769/attachment.html>


More information about the cfe-dev mailing list