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

[Pierre Rouleau]

On Mon, May 30, 2022 at 8:47 AM Paul Smith <psmith@gnu.org> wrote:

> 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
> unfortunately.
>
> 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.


OK, that makes sense.

>
> > > 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.
>
> Understood.  Thanks for your patience!


> 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.
>

In this particular case I might very well become concerned.
Not for the current state of the build system and current state of the code
and patches,
but because the number of patches will likely grow over time and it'd be
nice that the
code is somewhat more future-proof.

I never had to deal with this kind of maintenance issue in the past.
That's an interesting problem.  I'll read more about quilt if this can help
there.

Thanks for all the help!


-- 
/Pierre