On Tue, Jun 15, 2021 at 4:22 AM Mark Piffer <mark.pif...@gmail.com> wrote: > > My solution was to separate the build system into a (non-recursive) structure > of make files which each have roughly speaking only one recipe. You may raise > an eyebrow but I can assure you that the segregation of a build process in > this way works, at least for embedded development. Complicated dependency > trees with very diverse recipes are bundled into the few non-single-recipe > makefiles, which the master makefile easily tolerates. The .EXTRA_PREREQS are > needed only for housekeeping purposes, i.e. creating dependencies on > makefiles, process scripts and auto-dependencies without them getting into > the automated input/output set > of the build process where only real engineering work products are kept.
Sounds reasonable. Regarding the use cases for global .EXTRA_PREREQS that a previous poster asked about, this is one: it lets you state in one place that any change to the build rules themselves should trigger rebuild of everything, without having to paste Makefile $(wildcard *.mk) serialized_vars etc. everywhere. For my case at least it turned out there were only a couple places where 'umbrella' targets needed to be expressed as lists instead, so that's what I've done. Britton
