[cfe-dev] Question of compile class
Xiaohui Chen
xchen422 at uwo.ca
Thu Nov 6 16:48:31 PST 2014
yes, maybe i am a little out of date, i should dive into cmake and ninja.
On 11/06/14, Nikola Smiljanic <popizdeh at gmail.com> wrote:
> I'm not sure how long make takes to run if there's nothing to compile. But you should definitely check out cmake + ninja.
>
> On Fri, Nov 7, 2014 at 10:52 AM, Xiaohui Chen <xchen422 at uwo.ca> wrote:
>
> > yes, i know, the makefile will skip compiling the code if i do not change them, but it will still
> > go through some directories and say "nothing to do" i guess.
> >
> > it is ok, i can use the current solution. Thank you!
> >
> > On 11/06/14, Nikola Smiljanic <popizdeh at gmail.com> wrote:
> > > 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 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/c4d1a381/attachment.html>
More information about the cfe-dev
mailing list