Automatic Xref Tool for C++/QT/KDELibs

Daniel Berlin dan at
Thu Dec 13 19:46:00 GMT 2001

On Thu, 13 Dec 2001, Eva Brucherseifer wrote:

> On Thursday 13 December 2001 13:52, you wrote:
> > On Thursday, December 13, 2001, at 07:35  AM, Daniel Berlin wrote:
> > > On Thursday, December 13, 2001, at 03:40  AM, Eva Brucherseifer wrote:
> > >> On Mittwoch, 12. Dezember 2001 19:41, you wrote:
> > >>> Which is what cppx is, effectively.
> > >>> Well, okay, it slightly changes the dump format.
> > >>> You could also use something like gcc-xml.
> > >>
> > >> The problem with cppx is, that it patches the compiler. And since I
> > >> don't
> > >> want to exchange or recompile the compiler, I cannot use this tool. I
> > >> guess
> > >> most developers are happy with their compilers and don't want to change
> > >> anything.
> > >
> > > Errr, once could view the patched gcc as just another tool.
> > > Nobody says you have to replace your default compiler with it.
> > > Your argument makes little sense.
> > > --Dan
> >
> > Let me expand a bit further.
> > 1. Recompiling the compiler is no harder than compiling any other tool.
> > In fact, it's probably easier. GCC distributions are built so they can
> > be compiled with a minimum of tools. You don't even need bison, for
> > instance.  This is done on purpose.  GCC is not difficult, or even all
> > that time consuming, to recompile.  It takes less time to rebuild gcc on
> > my machine than it does to recompile  most other things.
> > 2. Making a gcc that uses a different name than "gcc" is trivial.  you
> > just add --program-suffix=<whatever> to configure, and when you "make
> > install", you'll end up with "gcc-<whatever>" being the binary name.
> > 3.  Nobody has asked any developer to change their compiler.
> >
> > If you really think any of this is too difficult for your developers,
> > than distribute modified gcc binaries for whatever platforms you have
> > access to, and put the source up so that people on other platforms can
> > build it as well.
> >
> > Where's the big deal here?
> Well, I know how to compile a compiler. Still it doesn't take 1 minute, but
> rather half an hour or more. I have some old SUNs here, there it takes some
> hours. The next point is, that I have about 6 linux machines + a number of
> SUNs here to administrate and I don't like to update all gcc packages by
> hand. My "developers" are students and unfortunately they cannot help me in
> setting up software.
> So before I do that, I must be pretty sure, that it's a big improvement to
> have a modified gcc. And I must be 100% sure, that the produced messages and
> the code are exaclty the same for the unmodified and the modified compiler.

Um, no you don't.

> I've compiled (and re-compiled) enough software to know, that there always
> can brake something, so that you spend 4 hours or more, to find the problem
> and fix it. Just an example: there is no patch of cppx for my compiler
> version available - so should I switch compiler versions? And I simply don't
> have the time to replace central elements, that my daily work depends on.
> Because of the same arguments, I hardly exchange a running kernel.

You missed it again.
You don't need to change your compiler.

> But I am not talking about me alone. Rather is the question, if kdevelop
> developers want to integrate something into their excellent tool, that
> requires the users to recompile their compiler (or add one). This doesn't
> seem to be an out-of-the-box solution.
> I am much more in favour, to extend a tool such as doxygen (
> doxygen has call diagrams already on their todo list and they already now
> have source browsers with links. So they have a parser an internal
> representation of the code anyway. The good thing with doxygen is
> - it works
> - it has a lot of (configurable) output formats
> - it is already integrated into kdevelop (2.2, don't know about gideon)
> - it's standalone and it has a graphical configuration tool
> - it comes with most distributions

to unsubscribe from this list send an email to kdevelop-request at with the following body:
unsubscribe »your-email-address«

More information about the KDevelop mailing list