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

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-01-09 06:27:59

   Hi.

> I've reverted all those changes, and the follow ups. If you are going to 
> make such changes please do them on a branch. They have a high 
> likelihood of breaking regression testing.

   Ok, thanks for the tip...

   In my defense though:
   - This was a small change grouped under a single commit and thus 
easily revertable.
   - Was done on the trunk and not on the release branch.
   - If it did break anything it would be quickly obvious that it did.
   - I ran all the Boost Build tests and they all passed.
   - I grepped through the Boost trunk and found no uses of 
__ACTION_RULE__ anywhere outside the Boost Build/Jam subfolders.
   - 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.
   - I checked no

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

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

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

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

   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.

   (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?

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

   Best regards,
     Jurko Gospodnetić