Re: [PATCH] newlib: merge iconvdata into top-level Makefile

Mike Frysinger <[email protected]> Mon, 24 Jan 2022 19:57:15 -0500
Newsgroups	gmane.comp.lib.newlib
Message-ID	<Ye9K6+OAlO/WVh6a@vapier>
On 24 Jan 2022 17:45, Corinna Vinschen wrote:
> Looks good, except, there's this local.mk again.  I don't think this
> name is overly helpful.  All Makefiles, even those just included by the
> master Makefile should be called Makefile.somethingorother, IMHO.  These
> are much easier to find for people new to the stuff.
> 
> Same goes for the already existing newlib/doc/local.mk which I missed
> when reviewing the patches...

tl;dr: i've wrestled with this exact issue for a while now, before even
newlib, and imo "local.mk" is currently the least-worst option.  i did not
use that here lightly, or invent it myself.

there isn't strong style guidance as to which name to use.  it's already in
use in binutils & gdb, and other GNU projects like automake and autoconf.

the GNU standards document is silent on the matter unfortunately:
https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html

some other OSS projects have used the name "Makemodule.am", and i think i've
seen "module.am" once or twice.  i dislike these as i don't think using the
".am" suffix is a good idea.  that implies automake itself will be processing
it which it doesn't.  the fact that it's included by Makefile.am somewhere is
incidental.  we have strong precedence that foo.in will produce foo, and that
foo.am will produce foo.in.  which doesn't happen here.

in general, i think we have pretty strong precedence that makefile frags
should be named ".mk".  that's a convention that goes back quite a long
way (i.e. BSD days), and is used commonly in GNU projects, including in
the toolchain repo now -- see /config/*.mk as many examples.

i'm acutely aware that we have multilib.am" in the root of the toolchain
projects, but that is the multilib logic that's kind of been bolted on in
places, so i wouldn't look to it for precedence.  imo it should get renamed
to "multilib.mk", but i don't have the willpower to shave that yak :p.

libgloss has a config/ subdir of makefile fragments that uses ".mh" and
".mt" (for makefile host & target frags), but that convention isn't used
anywhere else, and seems like it's on the way out.

so if we've settled on ".mk" as the suffix, let's focus on the basename.

i don't think "Makefile.mk" is a good idea name as it implies a tight
coupling to a "Makefile" in the samedir.  i've also never really seen
that before.  along those lines, i'm not keen on "Make<anything>.mk".

i have seen "module.mk" once or twice.  that might be slightly better
than "local.mk".

so all things considered, i think "local.mk" is what we should use.
-mike
signature.asc (application/pgp-signature, 833 B)