Re: [jamboost] msvc-tools.jam question

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-18 19:42:08

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <jamboost_at_[hidden]>; <jamboost_at_[hidden]>
Sent: Thursday, July 18, 2002 8:06 PM
Subject: Re: [jamboost] msvc-tools.jam question

> At 05:24 PM 7/18/2002, David Abrahams wrote:
>
> >> It there a reason for that?
> >
> >Yes. VC is being used to refer to the general protocol being used by a
> >whole host of toolsets which exted this one: como, intel-win32,
> >msvc-stlport, ...
> >
> >> OK if I change the actions name to:
> >>
> >> actions msvc-C++-action
> >>
> >> So that log analysis tools don't have to special case that compiler?
> >
> >It won't help because all those toolsets use the same actions. Your log
> >analysis should not rely on the action name for anything.
>
> The action name is the only way it knows what it is looking at.

Why don't you just look at the name of the target it's building? That
always has the correct toolset name in it.

> Building in
> more action names isn't a problem; it is just messy.

"just messy?" You clearly don't have to maintain the build system.

> >P.S. I've often said that trying to postprocess the results of the
build
> >process with an external tool is not likely to work well, and I think
you
> >are running into many of the problems I was thinking of.
>
> Actually, I was having a lot of trouble with the build residue.

That was part of what I thought would be unreliable.

> Once I
> switched to using the log analysis to update a permanent .xml file,
> everything start working much better.

I can see how that would help. I didn't realize you were doing that.

> > It is possible to
> >assemble the .html/XML/whatever from the build results within the build
> >system, and I think it would be easier.
>
> Right now, I'm scanning information from several sources:

<snip>

Sounds like a mess, but if you can manage it, more power to ya.

> > However, the test system
> >requirements still need to be understood first...
>
> The addition over the last couple of days of the .xml file as a history
> repository seems to have been a real step forward, and seemed to
stabilize
> right away. Once the entire current system is stable (and we are running
> daily regression tests), it is pretty easy to look at the data being
pulled
> from all those sources, and say "this is what is required."
>
> Long term, it would be much simpler and more reliable if the build system
> were to provide and update that information in a single, unified file in
> each target directory. Most of it is known during bjam processing - there
> just doesn't seem to be any way to get Boost.Build V1 to report it right
> now. Maybe in V2 it will be easier. But even right now the latest
> versions of the reporting software are doing a good job. They are
> capturing warning messages from compilers, for example, and other helpful
> stuff.

I'm glad things are working better now.

Cheers,
Dave