From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-01-09 06:27:59
> 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
- 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
>> * 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...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk