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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-03 15:36:11

Rene Rivera wrote:
>I just put a reworked version of Reece's patch into CVS. The
>functionality is the same but the implementation a slightly different in
>some places to: reduce the amount of code (by reusing existing bjam
>functions), doesn't have buffer size limits, has the hooks for
>implementing TMPNAME and TMPFILE (but are not implemented yet), and is
>more io efficient. I'll work up documentation soon.

Great!

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

> > The harder ones to expand would be $(TMPPATH), $(TMPNAME) and $(TMPFILE)
> > as these would require hooking into the expand.c logic in order to add
> > the path_tmpdir() and tmpnam() outputs to the string expansion. I am
> > leaving those for the moment, unless you can write them :).
>
>I did, except for having them calculate the values :-) Basically in
>variable.c there are now some hard-wired variables (in var_get). So we
>just need to implement the tmpnam functionality and hook it in there.

:) NOTE: There is a tmpnam C API function.

> > Note that there is a problem with the whitespace expansion in
> > var_string_file that I can't figure out.
>
>Well it's either fixed in the way I wrote it or I didn't notice. The one
>whitespace bug I did notice was of variables getting an extra space at
>the end of the expansion. AFAICT it's a long standing "bug" in Jam var
>expansion, so it's now fixed in both $() and @() expansion.

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

>Note, I did not make the BBv2 response file changes as I'd like you to
>build the new bjam and try it out before really using the @()
>functionality. So I await another, or the same if it just works, patch
>from you.

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.

>And another note, I made some local changes to the print module and I
>have it now consuming about 50% less memory :-)

Yay!

>And I keep remembering notes... The TMPDIR etc. vars as I implemented
>them can be used outside of the @() expansion.

Cool.

- Reece

 ------=_NextPart_000_1765_5b19_7cef Content-Type: application/octet-stream; name="response.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="response.diff"

[Attachment content not displayed.] ------=_NextPart_000_1765_5b19_7cef--