[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it possible to break from a GMAKE foreach loop and then exit from

From: Paul Smith
Subject: Re: Is it possible to break from a GMAKE foreach loop and then exit from make?
Date: Mon, 30 May 2022 08:47:44 -0400
User-agent: Evolution 3.44.1 (by

On Sun, 2022-05-29 at 21:53 -0400, Pierre Rouleau wrote:
> > It will work.  It's simple to test so did you try it and it didn't
> > work and that's why you're asking?
> I did try and it worked, but since I could not find documentation on
> it I wanted to double check.  I must say I find debugging large
> makefile sets difficult.

Makefile recipes are actually shell scripts, so to understand how to
write and debug makefiles you have to understand both makefiles and
shell scripting, and there's not one set of docs that covers both

In the case of recipes generally you just run the command and examine
the recipe that was generated by your scripting and see if it's right.

For debugging other things, you can use the $(info ...) to print
variables and other content, and/or use the "-p" option to print out
make's database of variables and rules.

> > The advantage of the "&&" is that your script is shorter which
> > means you'll be less likely to run into a limit for lots of patches
> > (although the limits in modern POSIX systems are pretty large).
> > 
> In what sense is the script shorter?   
> Is it not the same as with  the ; separator except that it acts as a
> logic AND?

I mean in the literal sense, as in the number of characters.  The
string "|| exit 1;" is 10 chars long and "&&" is 2 chars long.  So if
you have 1000 patches then the "exit" version will be 8000 chars longer
than the "&&" version.  Remember that the entire script is sent to the
shell in a single command line, like "sh -c '<script>'".  While command
length limits in modern POSIX systems are large they are not infinite
and this could be an issue, for some situations.

Of course this is just a stop-gap measure and it's probably best to
choose a different method, if you're concerned about these limits.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]