On Mon, 2022-05-30 at 13:44 -0400, Pierre Rouleau wrote: > 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.
quilt is, of course, an option but not the only one. You can do this with vanilla make as well. One way is to stop thinking of using loops inside of a single make recipe that does all the patching, and instead create a rule (probably an implicit rule) that applies a single patch, then use prerequisites to invoke that rule for each patch. The problem with this, in the case of patches, is that the order is very important so you really want to run this serially. It can be done but might be annoying. Another option if you can rely on a sufficiently-modern version of GNU make is to use make's $(file ...) function to generate a batch file then invoke the shell on that batch file rather than passing everything on the command line. Because $(file ...) operates entirely within make it doesn't run into the same set of issues that invoking a shell would. It may not be worth worrying about until you actually start to run into problems. Premature optimization is the cause of a lot off issues in programming, and also build systems :).
