> a) I want to test my changes in process_jam_log so that
> I can be sure that they don't break boost testing. Locally
> I can test that the support library_status and compiler_status.
>
> b) check in these changes knowing that they won't break
> testing. Note that since the output of process_jam_log
> isn't specified anywhere - there is no way I can really
> check that its correct other than by running the programs
> which use that output. - that is regression.py - and
> that one fails silently if the input isn't correct.
>
> c) then my library_status will work and I can
> ask users who have problems with the serialization
> library to run the tests on it. [...]
...
> Soooooo - THAT is what I'm looking for. Am I being
> unreasonable?

I'd like to point out one important thing -- nothing in
the above list appears to be related to Boost.Build,
therefore it probably should not be discussed on Boost.Build list,
but on the boost-testing list, where I cross-post this email,
and where all follow-up should be directed.

As far as testing process_jam_logs goes -- would you mind telling
what's missing in the current output? Basically, an easy way
to test your changes is to run old process_jam_logs, run new process_jam_logs,
and make sure that the produced xml files are identical.

As far as library_status.cpp goes, I've just looked at SVN at it
appears that file has large blocks of code common to compiler_status.cpp.
Except that it was reformatted to use different indentation, which makes
it impossible to understand the real differences. I don't think this
code duplication is OK.

Speaking about compiler_status.cpp, what you say is false. Here's what I've
just did:

Everything is from SVN HEAD. I have got the attached two files, and they
make sense to me. The only problem with those files is that all
tests are marked as having warnings; this is most
likely a result of:

1. Somebody changing process_jam_logs, and
2. Not reporting of warnings by the current web pages,
so the bogus warning remained unnoticed.

We can probably fix that, but I surely don't think that copy-pasting
compiler_status.cpp is the first approach to the fix.