Re: [boost] [RFC] Better error messages for errors detected atcom pile time

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-03-26 12:27:44

David Abrahams wrote:
> 
> booster.tgz (labelled "first draft") is all I could find.

That's what I meant, sorry.

> It looks like this just uses simple regex matching, which is always
> dangerous for anything that has to parse C++ types (the world is
> dangerous for that sort of tool in /any/ case!) -- for example, how do
> you deal with nested template constructs like vector<vector<double> >,
> since there's no paren-counting in a regex?

No need to, the rules I have work fine for nested types. Sure you can
always find a case to fool the rules, but in 99.99% of all cases it
works and it is a real helper. Well, the version in the files section
may be a bit older, thus not as stable and robust as my current version.

> > d) Remove warnings from the make-system and colorize the output to
> > better see what's happening
> 
> How are you colorizing things? I do most of my compilation through
> emacs; I think the colorization would need to happen in elisp code.

I'm using 'make' from the shell. Sure you have to define your own rules
if you want to use it in other environments... the main advantage is
that the rules are stored in simple textfiles and not within a complex
script (perl is IMHO a write-only-language). You can concentrate on the
rules instead of the tool. As the tool is independent of everything
else, I even use it to make the functions and their arguments from the
profiler-output readable. This limits you to regular expressions but no
one limits you to use only one tool. My point is: If it can be done by a
regular expression (as perfect as I need it), the tool is the right
thing. If you need something special that can't be done by a regular
expression - well, take something else. :)

> > e) Summarize and colorize CVS-output to highlight conflicts during
> > updates, etc.
> >
> > The problem is, that you can't change the compiler/language.
> 
> You mean that one invocation of the tool has to contain output from a
> single compiler?

No. But it helps. But you can apply as many ruleset in a single run as
you like. Or you chain the output. When I compile the modules of our
project, the compiler is invoked with several rulesets to summarize
STL-name, boost-names and some internal stuff. Some modules have
different rulesets to suppress expected warnings from other libraries.
If I type 'make', this is all that happens. When I use 'install_all' (a
script) inside a modules directory, the output (containing the processed
output from 'make') is run through a different ruleset to remove
unwanted warnings from the script and highlight the output so I can
track errors faster. Using 'install_all' outside of a special module
applies another set of rules. That way the rulesets are separated so it
is easier to maintain and extend them.

> I would be very interested in a tool which re-orders the instantiation
> backtrace from GCC: it's always in exactly the wrong order. Can you do
> that?

Not currently, as it works on a per-line base. But I'm looking for a way
to process several lines at once, so there might be a way to do so in
the future.

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de