Re: [Ctool-develop] using ctool as a library

[Shaun F. <fli...@so...>]

Stefan,

Rather than send a huge patch like this you could just become a ctool 
developer so you can use cvs also; for a large change it could go in on 
a branch first to be looked over by concerned parties. I'll just need 
your sourceforge username to add you.

I like the sound of your PrintTraversal, but I disagree with this not 
being in the library itself. This is a very common need: using the 
generated AST to swap arguments to a particular function, etc then 
reprinting the source.  Having it in the library brings the size of a 
simple program like this down to a page or two of code.

Also, the bison change is going to need to be an option in the 
makefile; my version of bison is apparently older, as its doing the 
dumb 'gram.cpp.h' thing.  Autoconf sounds good to me also.

Changing the library name to 'libctool.*' makes sense to me for both 
the shared and static versions.

I'm not going to merge these changes now, I'll wait till I hear from 
you about becoming a developer.

Thanks,
Shaun

On Thursday, July 31, 2003, at 11:37  PM, Stefan Seefeld wrote:

> Shaun Flisakowski wrote:
>> Limited forms of visitors exist, see TransUnit in project.h:
>>     void findStemnt( fnStemntCallback cb );
>>     void findFunctionDef( fnFunctionCallback cb );
>> and Expression in express.h:
>>     void findExpr( fnExprCallback cb );
>> The 'cgraph' example in examples/cgraph uses findFunctionDef() to  
>> demonstrate how to create a call-graph for a program.
>> I have my doubts that this method is going to be powerful enough to  
>> transfer the entire AST to another form though - they are intended 
>> for  users who need to collect information from the AST, or to make 
>> slight  tweaks to the AST before reprinting it.
>> If you try it, I'd like to hear your suggestions for improvements.
>
> ok, I had a first try tonight at this: I added 'accept' methods to
> a number of classes, which all accept a 'Traversal' object and call
> an appropriate method on it to resolve the dynamic type.
>
> I wrote a 'PrintTraversal' which should (once debugged and cleaned up)
> do all the work that is now implemented by the various 'print' methods.
> This is just an illustration of the pattern, but if you accept it, you
> could remove all the 'print' methods from the individual classes,
> as that code would then be completely contained in PrintTraversal.cpp.
>
> The idea is then that the actual library would only contain the parser,
> the individual node types, and the Traversal interface.
> The PrintTraversal (and any other Traversal implementations users want
> to implement) are part of the applications that actually use the 
> library.
>
> Specifically, the PrintTraversal would go into the 'ctdemo' 
> application,
> while the library would not contain any print functionality.
>
> Speaking of the library, do you think it would make sense to build
> it as a shared library ? Also, if you want to 'go public' with that,
> I'd suggest a somewhat longer name such as 'libctool.so' instead of the
> short and unspecific name 'libct.so'.
>
> Finally, I'd suggest to rework the build system a little to make the
> whole thing more flexible and portable. I'd suggest to use autoconf for
> that, and I'm willing to provide a patch.
>
> However, I'll be on vacation starting this weekend, so I'm only able
> to work more on this project in two weeks.
>
> Kind regards,
> 		Stefan
> ? src/PrintTraversal.cpp
> ? src/PrintTraversal.h
> ? src/Traversal.h
> Index: src/Makefile
> ===================================================================
> RCS file: /cvsroot/ctool/ctool/src/Makefile,v
> retrieving revision 1.3
> diff -u -r1.3 Makefile
> --- src/Makefile	17 Jul 2002 21:03:54 -0000	1.3
> +++ src/Makefile	1 Aug 2003 06:24:00 -0000
> @@ -53,8 +53,8 @@
>  #	Source files and directories
>  #
>
> -DEMO_C_MAIN = ctdemo.cpp
> -DEMO_C_OBJ = ctdemo.o
> +DEMO_C_MAIN = PrintTraversal.cpp ctdemo.cpp
> +DEMO_C_OBJ = PrintTraversal.o ctdemo.o
>
>  LIBCT_FILES = \
>      context.cpp \
> @@ -197,7 +197,7 @@
>
>  gram.cpp gram.h:	gram.y
>  	$(BISON) $(BISON_V) -d -b gram -o gram.cpp $<
> -	$(MV) gram.cpp.h gram.h
> +	$(MV) gram.hpp gram.h
>