[cfe-dev] Question of compile class
Xiaohui Chen
xchen422 at uwo.ca
Thu Nov 6 14:53:49 PST 2014
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 point 00090 /// for traversing an AST rooted at x. This method simply 00091 /// dispatches (i.e. forwards) to TraverseFoo(Foo *x) where Foo 00092 /// is the dynamic type of *x, which calls WalkUpFromFoo(x) and 00093 /// then recursively visits the child nodes of x. 00094 /// TraverseStmt(Stmt *x) and TraverseType(QualType x) work 00095 /// similarly. 00096 /// 2. WalkUpFromFoo(Foo *x) does task #2. It does not try to visit 00097 /// any child node of x. Instead, it first calls WalkUpFromBar(x) 00098 /// where Bar is the direct parent class of Foo (unless Foo has 00099 /// 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 same 00104 /// 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 visit 00097 /// any child node of x. Instead, it first calls WalkUpFromBar(x) 00098 /// where Bar is the direct parent class of Foo (unless Foo has 00099 /// 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/20141106/77ba63de/attachment.html>
More information about the cfe-dev
mailing list