Re: compiler hints

[Dale P. Smith]

Michael Livshin wrote:
> 
> thi <address@hidden> writes:
> 
> > why doesn't someone integrate guile w/ gcc / preprocessor already?
> 
> could you elaborate?

Well, I'll throw in my $.02.

There are lots of tools for analyzing C or C++ source code.  Stuff like
etags, cxref, idutils.  These tools all reimplement some form of the C
preprocessor or compiler.  Right now, you can convince gcc to generate
depenancy rules for Makefiles.  Why?  Because gcc already has all the
code to determine exactly what headers a certain source file includes. 
If you tried to write a special program, you would end up duplicating
code that gcc uses to gernate all the pre-defined #define's for the
target arch and compiler options.

Wouldn't it be great if there were well-defined hooks at parse time and
code generation time that you could attach scheme code for whatever you
wanted?  You could build databases that you could do all kinds of
queries against.  Where is this variable assigned to?  Does this file
use any definitions from header foo.h at all?  What classes inherit from
this class?  Who calls this function (including calls through a
pointer)?

I'm sure there would be uses down the road that the current implementors
couldn't have imagined.

We started using dot (from at&t graphviz) at Bell+Howell for all kinds
of stuff. Module dependancies in CVS.  Process trees (like pstree). 
.DLL and .so depenancies.   At that time I really wished there was some
way to hook in to gcc.  I made some hacks to cxref, but we really wanted
to look at C++ code, which cxref couldn't handle.

I hope that made some sense.

-Dale
-- 
Dale P. Smith
Treasurer, Cleveland Linux Users Group http://cleveland.lug.net
Senior Systems Consultant, Altus Technologies Corporation
address@hidden
440-746-9000 x309