Re: [jamboost] Re: [BBv2] [bjam] Native response file support

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-11-05 03:20:31

Reece Dunn wrote:
> Rene Rivera wrote:
>>Reece Dunn wrote:
>>
>>>STDOUT and STDERR are easy: just compare the string for $(STDOUT) and
>>>$(STDERR), then associate the output with the corresponding FILE *.
>>
>>Even though I left the implementation of those in. They turn out to not
>>work as I was hoping and they are currently disabled. The problem is
>>that at the time the @() is expanded out it's done during the expansion
>>of the action text. That expansion is much earlier than the execution of
>>the action text so that output goes to the equivalent of nowhere.
> 
> 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

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

> The bug I was referring to was that doing @($(STDOUT):E=
> -D$(DEFINES)) does not record the newline character and place it in *each 
> entry in the expansion* of the defines, so you have each define on a new 
> line. You also get a space after each entry (when processing the list). I 
> don't know how to fix these and they aren't major issues as there is a 
> workaround for the first issue by having $(nl)-D$(DEFINES) where $(nl) is 
> equivalent to "\n".

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

1. Only contiguous portions of input text are evaluated for expansion, 
i.e. parsed tokens. So *any* whitespace will break up the expansion. 
Hence why you need the $(nl) trick.

2. When expanding a variable, all vars are lists, it is expanded into 
whitespace delimited values, the whitespace used happens to be the 
single space (' '). Hence the extra spaces either at the start or end of 
the lines when using $(nl) trick. The "bug" that I fixed was that it was 
also appending that space at the end of the list, regardless of how many 
items on the list. So at least now if one has 1 element there are no 
extra spaces tacked onto the expansion.

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

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

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org