From: Nicolas Fleury (nidoizo_at_[hidden])
Date: 2005-04-01 11:56:58
Nicolas Fleury wrote:
> Is there any way to disable the 2047 limit for actions with boost.jam.
> If not, if I make a patch for it will it be welcome (like a built-in
> variable)? (I ask because the latest boost.jam binaries are not really
> recent.) The limit is just there in case it is the real limit for the
> OS, right? If a custom JAMSHELL is used, sky is the limit?
> Thx and regards,
> Nicolas Fleury
I finally found that 2001 message from Craig McPheeters on a Perforce
Bat files on NT can grow to be really large without problem, as long as
each of the lines in it are not longer than the line length limitation.
2047 characters or so sounds about right.
There is a space/newline expansion trick in the jamming archives, I would
hate to give the wrong attribution to it...I think Diane explained it
first? Look through the archives for the original posting.
The trick is to create two jam variables:
SPACE = " " ;
NEWLINE = "
Because of the way Jam does its variable expansion, you can use the
expansion of these variables in creative ways. If you need an action to
record all of the $(>) files into another file, the easy way is:
echo $(>) >> $(<)
but that can violate the line length limitation on NT. The trick is to
do this instead:
It took me a little while to understand its beauty, but now whenever I
use that trick, I get a little smile on my face. Thanks to the original
poster for showing it to me.
There is an extension in my guest branch which removes the limitation on
the size of an action block. With that extension, and the trick above, its
possible to safely create really large action blocks on NT (or Unix) and
have them always work. Often that trick is enough to get around the
limitations of cmd.exe.
I must admit the trick left me perplex... I'm wondering if a simpler
solution, like having some way to disable the limit for a specific
action, even if it affects a bit its performance.
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