18 messages in com.perforce.jamming[jamming] Expressing "lazy always upd...
FromSent OnAttachments
Matt Armstrong03 Jan 2002 16:37 
Craig McPheeters03 Jan 2002 18:49 
Roesler, Randy03 Jan 2002 19:04 
Arnt Gulbrandsen04 Jan 2002 04:39 
Matt Armstrong04 Jan 2002 14:27 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)04 Jan 2002 14:36 
Craig McPheeters04 Jan 2002 14:59 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)04 Jan 2002 15:08 
Matt Armstrong04 Jan 2002 23:48 
Matt Armstrong05 Jan 2002 00:20 
Arnt Gulbrandsen07 Jan 2002 02:33 
Matt Armstrong07 Jan 2002 09:16 
Craig McPheeters07 Jan 2002 13:28 
Craig McPheeters07 Jan 2002 13:57 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)11 Jan 2002 15:18 
Matt Armstrong11 Jan 2002 16:15 
David Abrahams" <david.abrahams@rcn.com (David Abrahams)11 Jan 2002 16:40 
Lex Spoon12 Jan 2002 07:48 
Subject:[jamming] Expressing "lazy always update" intermediate files
From:Craig McPheeters (cmcp@aw.sgi.com)
Date:01/07/2002 01:57:20 PM
List:com.perforce.jamming

Subject: Re: [jamming] Expressing "lazy always update" intermediate files From: Matt Armstrong <matt+jamm@lickey.com> Date: Mon, 07 Jan 2002 10:17:19 -0700

Arnt Gulbrandsen <ar@gulbrandsen.priv.no> writes:

Matt Armstrong <matt+jamm@lickey.com>

Doing it in a single action is impractical due to the limitations of my shell (Win NT cmd.exe).

If you don't mind a bit of topic drift, I'm curious about that. Could you describe what would happen?

Actually I don't think it is NT specific -- these "response files" are huge, so they must be built with piecemeal actions. So, it isn't possible to build all the response files with a single actions block.

...

The limitations on the size of an action block can be removed with one of the extensions in my branch. I find with unlimited action sizes, and the newline expansion trick, the standard NT shell can be used for most of my actions. Where more complex logic is needed, I use perl.

The way to make this more useful is to set a bunch of variables on some target, each of which can grow to large lists.

For example, if you're building a shared object, you may want the list of object files and the list of archives in separate lists. I do this by setting different variables on the target. ie, something like:

OBJS on libfoo.dll += foo.o ; OBJS on libfoo.dll += bar.o ; ARCHIVES on libfoo.dll += liba.lib ; ARCHIVES on libfoo.dll += libb.lib ; ARCHIVES on libfoo.dll += libc.lib ;

where the above is done internally by my other rules. Then in the action block for building the shared object:

actions myBuildShared bind OBJS ARCHIVES { if exist $(<).objs $(RM) $(<).objs $(TOUCH) $(<).objs echo$(SPACE)$(OBJS)$(SPACE)>>$(<).objs$(NEWLINE)

if exist $(<).archives $(RM) $(<).archives $(TOUCH) $(<).archives echo$(SPACE)$(ARCHIVES)$(SPACE)>>$(<).archives$(NEWLINE)

$(LINK) ... @$(<).objs @$(<).archives ... }

it is sometimes better to pre-process files via separate actions, but the number of times I do that is much less now that it was when action blocks had a fixed size limit.

Cheers, Craig.