From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-23 10:50:40
David Abrahams wrote:
> Reece Dunn <msclrhd_at_[hidden]> writes:
>>David Abrahams wrote:
>>>That's a little ugly. You get a compilation error; you want to
>>>diagnose it. Then you have to rebuild with --show-response-files,
>>>copy the response file contents and the rest of the command line,
>>>replace -c with -E, and invoke the compiler again to preprocess.
>>Option  (see also my [BBv2] response files - behaviour change
>>(and solution!) thread for details) will print the response file
>>content along with the command line on failure.
>>Alternatively, you can copy/rename the response file on failure to
>>keep it around, while allowing the response file target to be
>>regenerated properly and preventing problems with the above.
> It's not bad -- better than nothing for sure -- but the command line
> as it appears will refer to the wrong file if you want to retry the
> compilation thereafter.
We can always add this to the documentation, noting the problem with
having the rsp file present when rebuilding through BBv2.
Also: one benefit of displaying the response file content on failure is
that it allows people who don't have access to the rsp file to run the
command without BBv2. An example of this would be someone who sees an
error in the regression tests and wants to investigate. Granted, they
have the hasstle of copying and pasting the content to a file, but at
least it gives them that opportunity.
It would also allow them to better investigate an error by seeing what
defines and include paths are being used without having to dig into the
correct RSP file.
So, the current solution would be either:
1. fix the problem and keep the current behaviour (not sure how this
would be implemented);
2. print out the response file content on failure;
3. keep the rsp file, but rename it (e.g. main.rsp.old);
If you, Volodya or anyone else has a better solution feel free to add it
to the discussion.
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