Re: [Boost-build] module_action test broken by Boost.Jam changes.

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-01-09 11:52:16

Jurko Gospodnetic' wrote:
>    - Was done on the trunk and not on the release branch.

The problem immediate problem would have been (and still may be 
depending on update cycles) that testers would have updated the trunk 
BBv2 tools plus the release (3.1.16) bjam and possibly gotten an error 
because of the former is using the wrong interface of the latter.

>    - If it did break anything it would be quickly obvious that it did.

When it comes to testing for a release there is not current quickly. As 
soon as one or more testers break they loose one cycle. This may be 
anywhere from minutes to days of lost work.

>    - I ran all the Boost Build tests and they all passed.

There are also bjam test. And the Boost tests themselves to consider.

>    - I grepped through the Boost trunk and found no uses of 
> __ACTION_RULE__ anywhere outside the Boost Build/Jam subfolders.

One of those uses is code put in by Dave and myself for producing XML 
output for submission to the Bitten testing system. And hence something 
that would have likely broken.

>    - Change included an update to build-system.jam so that the 
> constructed XML build report contained the same output as before up-to a 
> possibly added additional trailing newline.

OK. But I think what you didn't realize is that the BBv2 code must be 
able to work with various bjam versions. Not only does Boost regression 
testing function this way. But it is very common for users to mix and 
match bjam and BBv2, for the plain reason that they tend to install 
system provided bjam's which is usually older version than the src 
included with BBv2.

>>> Consequences:
>>>    * Final __ACTION_RULE__ rule parameter has changed from output ? to 
>>> output-lines *.
>> It is too late to change this behavior. We have releases that rely on it 
>> and would likely break in a variety of ways.
> 
>    Ouch, this does not feel right. Does not have tests, can not be used 
> for the purpose I read it should be used for (testing action output) and 
> can not be changed... :-(

I'm not sure I understand your comment. It's designed to faithfully 
capture the output of the actions run. Nothing more.

>    Could you at least add tests demonstrating the behavior you need?

I'll try to add some bjam tests. Sorry the tests for bjam are slim but I 
only recently started on adding those. But I thought the behavior was 
obvious for __ACTION_RULE__ and __TIMING_RULE__ (and SYSTEM/SHELL) 
especially since they are all documented.

>    Btw. the problem with the original/reverted implementation is that 
> the output string contains newline sequences encoded in the way that the 
> action encoded them - most likely \n or \r\n based on the host platform 
> and/or standard C library.

It's not based on the C library, or strictly speaking the host platform. 
It is a precise reproduction of the output produced by the programs run 
in actions.

> Jam, then can not handle such strings 
> correctly as for example: MATCH rule does not handle \n intuitively in 
> its regex format (internal regex implementation treats it as an or).

There are many examples in code where we handle MATCH and newlines (and 
just about any Jam code dealing with newlines) by always using the 
platform newline with something like:

   NL = "
" ;

>    E.g. If you have an action displaying the text: 'Something' (minus 
> the quotes) and a newline on *NIX it would get output (and collected via 
> a pipe by bjam) as 'Something\n' and on Windows as 'Something\r\n'. Then 
> if you attempt pass it to the registered __ACTION_RULE__ you get that
> expanded value in the $(output) variable. If you now try to output that 
> value from bjam it gets output ok on *NIX but on Windows the \n gets 
> expanded again so you get 'Something\r\r\n'.

AFAIK if you echo it from within bjam it doesn't re-expand the newlines. 
How/where is it output such that it's getting reparsed?

>    Some alternatives to my solution that could possibly better suit you:
> 
>    (1.) Update the command output passed to the __ACTION_RULE__ rule so 
> that all \r\n sequences get converted to \n? That would not solve the 
> MATCH problem but would solve the output problem.

Not an option. I want the returned string to accurately reflect the 
content really produced. It would also cause a discrepancy with how we 
handle newlines everywhere else in bjam.

>    (2.) Update the failing tests that parse the action output so that 
> they specify the -d+1 option and expect to see action names besides 
> their output. This is the 'easy way' to fix these tests but one which I 
> have not done only because they pointed me to __ACTION_RULE__ problems.
> 
>    Any other suggestions?

(3) Normalize the __ACTION_RULE__ output as needed where you are 
processing it. I'm guessing this is a problem with Python reparsing the 
output. Hence fixing it on that end seems more appropriate.

There are a few variations on the theme of post-processing the output of 
__ACTION_RULE__ that can apply. But I don't know enough abut how you 
want to use it to suggest something more specific.

>    Ok, in conclusion, I'll give up on the __ACTION_RULE__ changes, 
> correct the failing tests as described above under alternative (2.) and 
> prepare a separate test demonstrating the __ACTION_RULE__ problem which 
> you can then accept or discard...

OK.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo