Automatic Xref Tool for C++/QT/KDELibs

Eva Brucherseifer eva at kde.org
Thu Dec 13 14:27:13 GMT 2001


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. 
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.

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 (www.doxygen.org). 
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

Please remember, that a lot of people prefer kdevelop over emacs and other 
editors, because it is graphical and easy to use. Most of them even don't 
understand autoconf and automake - so don't expect the standard user to 
recompile gcc. 

Greetings,
eva

>
> --Dan
>
>
> -
> to unsubscribe from this list send an email to
> kdevelop-request at kdevelop.org with the following body: unsubscribe
> ťyour-email-addressŤ

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe ťyour-email-addressŤ



More information about the KDevelop mailing list