From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-26 09:12:59
----- Original Message -----
From: "Daniel Frey" <daniel.frey_at_[hidden]>
> Maybe you want to have a look at booster.zip in the files section.
booster.tgz (labelled "first draft") is all I could find.
> got almost no attention from this group so far but it may be the time
> for a second chance :) An updated version is available if anyone would
> like to see it. I'm using it for a number of things here in the
> a) Convert long STL-names to readable names, e.g. std::map<
> std::string >
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?
> b) Convert (some) long boost-names to readable names, e.g.
> c) Remove warnings from external libraries about comparing int's to
> unsigned int's, etc. that are useless but always there. Roguewave (as
> example) has warnings about reordering the initialization list of some
> ctor's but they refused to change the code). Instead of patching there
> code, I just added a regex to remove the warning from the compiler
> d) Replace our internal typedef-ed names (RWDecimal<
> RWMultiPrecisionInt< 3 > > becomes Base::decimal, etc.)
> 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.
> 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
> But you can
> write a macro to output strings from the code as a warning from the
> compiler. These warnings can be used to generate good error messages.
> Sure the tool I wrote is not yet ready for these kind of things, there
> are several extension that could be useful: Regular expressions that
> applied to several lines at once (allowing to summarize the call stack
> and spread errors - that is errors that can only be detected when
> looking at several lines of output at once). Maybe includes for the
> rulesets would be useful. You may have a look for yourself and see if
> you like it...
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
I am interested in making sure that there are hooks available for this
sort of tool in v2 of Boost.Build.
Ultimately, for my purposes, a rewrite of emacs' compilation-mode is
what's really needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk