26 messages in com.perforce.jamming[jamming] new release of "FT Jam"
FromSent OnAttachments
David Abrahams18 Jun 2001 15:20 
Brett Calcott20 Jun 2001 14:29 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)20 Jun 2001 16:09 
John Belmonte20 Jun 2001 22:56 
David Abrahams21 Jun 2001 05:26 
John Belmonte21 Jun 2001 05:44 
David Abrahams21 Jun 2001 05:50 
David Turner26 Jun 2001 01:24 
David Abrahams26 Jun 2001 06:01 
David Turner26 Jun 2001 08:07 
David Turner26 Jun 2001 08:40 
David Turner26 Jun 2001 08:56 
David Abrahams26 Jun 2001 09:41 
David Abrahams26 Jun 2001 10:12 
David Turner26 Jun 2001 11:35 
Beman Dawes26 Jun 2001 11:40 
David Turner26 Jun 2001 14:44 
Chris Antos26 Jun 2001 17:18 
Dave Lewis26 Jun 2001 20:25 
David Abrahams27 Jun 2001 04:56 
Dave Lewis27 Jun 2001 07:54 
Paul Moore27 Jun 2001 15:14 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)27 Jun 2001 17:31 
Paul Moore28 Jun 2001 12:46 
David Abrahams28 Jun 2001 14:54 
Paul Moore30 Jun 2001 09:59 
Subject:[jamming] new release of "FT Jam"
From:Chris Antos (chri@windows.microsoft.com)
Date:06/26/2001 05:18:28 PM
List:com.perforce.jamming

| Another moderately-high priority for me, and one | I've just discovered, is to open up the MAXLINE | constant for Windows NT. I am not interested in | supporting NT3.5 (sorry!) and it is fairly easy | to come up with a link command line that exceeds | the 996 characters allocated by the default Jam | on NT. If you don't feel comfortable about folding | that change into FTJam, I would be "forced" to make | the modification myself, resulting in (IMO) a very | silly code fork.

I had two problems with the 996 limit -- (1) the limit was frequently hit when a rule has a bug, but I couldn't see what the bug was, because it only told me "too big"; (2) some actions are multiple lines long, and get run as batch files, therefore it may be that the actions are say 4 lines where line 1 is 700 chars long, line 2 is 20, line 3 is 300, line 4 is 20. But the batch file would have run fine. In particular, this causes problems for my C++/Sbr and Pch/Sbr rules, which have to call "touch" on the long target filenames after they're produced, to force them to have consistent timestamps.

However, Jam does need some concept of a maximum line length, so it can optimize the PIECEMEAL actions. Btw, accordingly to comments in the Jam source, NT isn't able to execute command lines longer than 996 characters (I don't know if that's really true, I've never tried). So just increasing MAXLINE may not solve your problem. Perhaps in your case it would be better to rewrite various actions to create/update an input file, so the Link actions can simply refer to the input file.

Anyway, here's what I did for a quick improvement to address my two issues described above:

In jam.h, added this after the #ifndef MAXLINE around line 421:

# ifndef MAXCMD # define MAXCMD 10240 /* longest command string */ # endif

In command.h, tweaked the "struct _cmd" so:

char buf[ MAXCMD ]; /* actual commands */

In command.h and command.c, tweaked prototype for "cmd_new" so:

LIST *shell, /* $(SHELL) (freed) */ int outsize ); /* max number of chars */

In command.c, tweaked the code for "cmd_new" so:

if( var_string( rule->actions, cmd->buf, outsize, &cmd->args ) < 0 )

In make1.c, inserted this line immediately at the top of the "do..while" loop in "make1cmds":

int outsize = ( rule->flags & RULE_PIECEMEAL ) ? MAXLINE : MAXCMD;

In make1.c, added an extra parameter to the end of the "cmd_new" call:

list_copy( L0, shell ), outsize );

In make1.c, parameterized the "actions too long (max ###)" message:

printf( "%s actions too long (max %d)!\n", rule->name, outsize );

End result -- Jam is still able to tweak PIECEMEAL actions for each OS, but for other actions Jam lets the OS figure out whether the lines are too long. Hope this helps!

// chris