On 26 Jan 2022 13:32, Corinna Vinschen wrote:
> On Jan 25 16:19, Mike Frysinger wrote:
> > On 25 Jan 2022 13:27, Corinna Vinschen wrote:
> > > Local.mk is neither a name speaking for itself, nor does it stand out
> > > due to being one of very few files in a dir starting with uppercase, or
> > > due to its catchphrase "Make...".  In terms of easy recognition for
> > > people trying to wrap their head around the build system and trying to
> > > find the right place to add or improve build rules, local.mk isn't
> > > overly helpful.
> > > 
> > > The *.mk files in Free/Open/NetBSD are not just called local.mk and are
> > > spread out over all the subdirs.  Most of these files are in the sys/conf
> > > and /share/mk dirs and have a speaking name like kern.opts.mk, etc.
> > > 
> > > In the core kernel and lib subdirs all BSDs use files called Makefile.inc,
> > > actually.
> > > 
> > > Therefore I would prefer Makefile.inc, too, as name for the Makefile
> > > snippets in our various subdirs, if you don't mind.
> > 
> > "local" is communicating that this is make code local to this directory.
> > ".mk" is communicating that this is a small make fragment/module.  taken
> > together, they say this is a local make fragment/module for this dir.
> > 
> > Makefile.inc is a bad name and deviates from what all other GNU/toolchain
> > projects are adopting.  i don't think newlib should be "innovating" here.
> > 
> > that said, i'm not the newlib maintainer, and if the newlib maintainer(s)
> > want to make "Makefile.inc" a hard requirement and not approve commits
> > using "local.mk", then that's the answer.  i disagree, but i don't get
> > the final say.
> 
> Either Makefile.inc, or create a newlib/config dir, move the .mk files
> there and give them names matching their subdir (preferred) or task.

creating a parallel tree of .mk files disconnected from the source files
they're responsible for enumerating is objectively worse by all metrics.
i'll respin the patches with the bad "Makefile.inc" name you require.
-mike