Re: [jamboost] msvc-tools.jam question

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-18 19:06:27

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. Building in 
more action names isn't a problem; it is just messy.

>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. Once I 
switched to using the log analysis to update a permanent .xml file, 
everything start working much better.

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

* Residue left by the build system in the target directory.
(This is really more than one source, as the information is
spread over several files.)

* The log file captured from bjam.

* The output of the config_info.cpp test.

* The toolset .jam file.

* The status/Jamfile.

* The .xml file left in the target directory by prior bjam runs
or prior actions.

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

--Beman