Re: make(1) guru question

2004-04-06 Thread Ruslan Ermilov
On Tue, Apr 06, 2004 at 12:11:35PM -0700, Luigi Rizzo wrote:
> On Tue, Apr 06, 2004 at 08:26:00PM +0200, Jens Schweikhardt wrote:
> > Fellow hackers,
> > 
> > suppose you have a long list of files in a make variable V, exceeding
> > kern.argmax. This means there is no way you can write a rule where $(V)
> > is a command argument in any way shape or form. There is also no way to
> > pass the value of V to xargs that I know of. For example with this
> 
> depending on the use, you might use something like
> 
>   make -V variable_name | xargs ...
> 
> within the makefile. I got the suggestion from someone long ago
> when I had this problem with src/sys/conf/Makefile.i386
> 
I can only confirm that this is the only known solution so far.


Cheers,
-- 
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make(1) guru question

2004-04-06 Thread Luigi Rizzo
On Tue, Apr 06, 2004 at 08:26:00PM +0200, Jens Schweikhardt wrote:
> Fellow hackers,
> 
> suppose you have a long list of files in a make variable V, exceeding
> kern.argmax. This means there is no way you can write a rule where $(V)
> is a command argument in any way shape or form. There is also no way to
> pass the value of V to xargs that I know of. For example with this

depending on the use, you might use something like

make -V variable_name | xargs ...

within the makefile. I got the suggestion from someone long ago
when I had this problem with src/sys/conf/Makefile.i386

cheers
luigi

> Makefile:
> 
>   # Make V exceed kern.argmax (64K).
>   V != jot 12440
>   all:
>   @ echo $(V)
> 
> This fails with
> 
>   echo:Argument list too long
>   *** Error code 1
> 
> Furthermore the workaround of creating a process for each file in V with
> 
>   V != jot 12440
>   all:
>   .for v in $(V)
>   @ echo $(v)
>   .endfor
> 
> is not acceptable because it creates too much overhead for process
> creation (think of echo being an expensive command.) Question: is there
> any other way (short of increasing kern.argmax) to maybe divide and
> conquer the V contents by use of substitution magic? I'm thinking of
> something along repeatedly cramming N items in some variable and then
> calling echo less often.
> 
> The original problem can be found in
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/52765
> 
> Regards,
> 
>   Jens
> -- 
> Jens Schweikhardt http://www.schweikhardt.net/
> SIGSIG -- signature too long (core dumped)
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


make(1) guru question

2004-04-06 Thread Jens Schweikhardt
Fellow hackers,

suppose you have a long list of files in a make variable V, exceeding
kern.argmax. This means there is no way you can write a rule where $(V)
is a command argument in any way shape or form. There is also no way to
pass the value of V to xargs that I know of. For example with this
Makefile:

# Make V exceed kern.argmax (64K).
V != jot 12440
all:
@ echo $(V)

This fails with

echo:Argument list too long
*** Error code 1

Furthermore the workaround of creating a process for each file in V with

V != jot 12440
all:
.for v in $(V)
@ echo $(v)
.endfor

is not acceptable because it creates too much overhead for process
creation (think of echo being an expensive command.) Question: is there
any other way (short of increasing kern.argmax) to maybe divide and
conquer the V contents by use of substitution magic? I'm thinking of
something along repeatedly cramming N items in some variable and then
calling echo less often.

The original problem can be found in
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/52765

Regards,

Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"