Re: [BBv2] fix for response file regeneration

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-23 07:44:12

Reece Dunn <msclrhd_at_[hidden]> writes:

> David Abrahams wrote:
>> Reece Dunn <msclrhd_at_[hidden]> writes:
>>>David Abrahams <dave <at> boost-consulting.com> writes:
>>>>Reece Dunn <msclrhd <at> hotmail.com> writes:
>>>>>David Abrahams wrote:
>>>>>>That just leads me to ask what's missing from the bjam core that we
>>>>>>can't implement the same behavior without resorting to extending bjam
>>>>>>specifically for response files?
>>>
>>>>>2. The main problem with the current response file code is that RSP 
>>>>>files are being treated as a target, so if you specify to always 
>>>>>generate the RSP file, it will recompile and relink the project that 
>>>>>uses them.
>>>>
>>>>Isn't that what TEMPORARY is supposed to do? The idea is that you can
>>>>delete TEMPORARY object files after creating a library without causing
>>>>the library to be rebuilt.
>>>
>>>The problem is that if the target fails, the response file is kept around *but*
>>>the action to regenerate the response file isn't called, so the old response
>>>file is used.
>> 
>> Have you looked at the RMOLD rule?
>
> I have tried:
> TEMPORARY $(rsp) ;
> RMOLD $(rsp) ;
> and haven't noticed any change :(.
>
>>>I am not too bothered about the rule+action interface, more the things that BBv2
>>>adds like the features, toolsets, etc.
>> 
>> That stuff *is* BB, so any version on a new foundation would preserve
>> it.
>
> :)
>
>>>So if I understand it:
>>>* BJam will be BJam+Python allowing you to run Python code from
>>>Jamfile/Sconsfile build scripts
>>>* Scons will be responsible for the rule+action+target logic that Jam was
>>>previously responsible for
>>>* BBpy will add features, toolsets and all the fancy stuff I expect from BB :)
>> 
>> If we get to the point of replacing the build engine with Scons, yes.
>
> :)
>
>> Why would we want to keep the response files for failed targets? Oh,
>> right, it's that whole mess with wanting to recreate the command
>> manually :(
>
> Would it be possible to do something like:
> if (failed)
> {
> ECHO "== RESPONSE FILE ==" ;
> ECHO $(rsp-contents) ;
> ECHO "== END OF RESPONSE FILE ==" ;
> RM $(rsp) ;
> }
> so we don't need to keep response files around, thus removing the 
> problem, but still allowing users to recreate the command manually.

That would be a little nasty, but perhaps acceptable. What I really
want more than anything is something that will preprocess a source
file to the standard output. Actually, given a *source* file/target
name on the command-line I'd like to be able to build all targets of
which that file/target is an immediate dependency. I'd like to be
able to optionally:

- force only dependents to rebuild
- force everything to rebuild (as with -a)
- rebuild only on demand

> Or, use a --show-response-files option that will do an
> ECHO $(rsp-contents) ;
> when the response file is created, removing the need for any spercial 
> failure detection. NOTE: This (or something similar) is what Matt's code 
> does.

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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com