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.
>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
on Windows and
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
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 :-)
>And I keep remembering notes... The TMPDIR etc. vars as I implemented
>them can be used outside of the @() expansion.
------=_NextPart_000_1765_5b19_7cef Content-Type: application/octet-stream; name="response.diff"
Content-Disposition: attachment; filename="response.diff"
[Attachment content not displayed.] ------=_NextPart_000_1765_5b19_7cef--
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