public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: newlib@sourceware.org
Subject: Re: [PATCH] newlib: merge iconvdata into top-level Makefile
Date: Wed, 26 Jan 2022 21:49:14 -0500	[thread overview]
Message-ID: <YfIIKrVIE+GzD8od@vapier> (raw)
In-Reply-To: <YfE/Uo05/OJ1JT4/@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-01-27  2:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-22  6:04 Mike Frysinger
2022-01-24 16:45 ` Corinna Vinschen
2022-01-25  0:57   ` Mike Frysinger
2022-01-25 12:27     ` Corinna Vinschen
2022-01-25 21:19       ` Mike Frysinger
2022-01-26 12:32         ` Corinna Vinschen
2022-01-27  2:49           ` Mike Frysinger [this message]
2022-01-27  2:50 ` [PATCH v2] " Mike Frysinger
2022-01-27 14:50   ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YfIIKrVIE+GzD8od@vapier \
    --to=vapier@gentoo.org \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).