Re: [Boost-build] [jamboost] Re: [BBv2] [bjam] Native response file support

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-05 04:31:46

Rene Rivera wrote:
> Reece Dunn wrote:
>> Rene Rivera wrote:
>>> Reece Dunn wrote:
>>>
>> Ah well... for STDOUT, we could write to an anonymous file, then expand the 
>> @(...) to:
>>
>>    type anonymous-file
>>
>> on Windows and
>>
>>    cat anonymous-file
>>
>> on cygwin and *nix. Not sure about STDERR, though.
> 
> Good idea. I'll run with that :-) For STDERR one would redirect to the 
> correct channel:
> 
>      type/cat anon-file 1>&2

Cool.

>> :) NOTE: There is a tmpnam C API function.
> 
> If only things where that easy ;-) The tmpnam functionality happens to 
> generate some horrid names when using the VC runtime. And I have no clue 
> how it badly it behaves across platforms. So instead I implemented 
> something more "reasonable".

:( Yeah, I did notice that VC tends to produce some strange names.

> Ah, yea, those aren't bugs. That's just the way variable expansion works:

Ok. Thanks for the clarification.

>> I have taken the new code and verified the patch works :). I have attached 
>> the same msvc.jam and cw.jam patch as my tests didn't encounter any issues 
>> with your modifications.
> 
> OK, I just put in your changes. It reduced my test case from 454223142B 
> to 381162374B. Or about 73M savings, i.e. ~16% less.

Great :)

>>> And another note, I made some local changes to the print module and I
>>> have it now consuming about 50% less memory :-)
>> Yay!
> 
> Oops, should have been 25%. But of course your changes made that 100% 
> :-) I'll check them them in eventually when I implement the STDOUT and 
> STDERR as above.

:) With your local changes plus mine, we are at about 40% (but yours 
will have improved response file generation because that was dependant 
on the print logic, so it may be closer to 30%).

Now... on to the next big memory consumer :).

- Reece