Automatic Xref Tool for C++/QT/KDELibs

[Daniel Berlin]

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.
NOTHING REQUIRES YOU TO USE THE NEW GCC AS YOUR COMPILER, YOU CAN GIVE IT
A DIFFERENT NAME.

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





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