From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 102BA385DC2E for ; Tue, 25 Jan 2022 21:19:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 102BA385DC2E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id 851163430E3; Tue, 25 Jan 2022 21:19:52 +0000 (UTC) Date: Tue, 25 Jan 2022 16:19:56 -0500 From: Mike Frysinger To: newlib@sourceware.org Subject: Re: [PATCH] newlib: merge iconvdata into top-level Makefile Message-ID: Mail-Followup-To: newlib@sourceware.org References: <20220122060458.7539-1-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n7s/dQvFFbn8Klxl" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 21:19:56 -0000 --n7s/dQvFFbn8Klxl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 25 Jan 2022 13:27, Corinna Vinschen wrote: > On Jan 24 19:57, Mike Frysinger wrote: > > 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 t= he > > > master Makefile should be called Makefile.somethingorother, IMHO. Th= ese > > > are much easier to find for people new to the stuff. > > >=20 > > > Same goes for the already existing newlib/doc/local.mk which I missed > > > when reviewing the patches... > >=20 > > 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. > >=20 > > there isn't strong style guidance as to which name to use. it's alread= y in > > use in binutils & gdb, and other GNU projects like automake and autocon= f. > >=20 > > the GNU standards document is silent on the matter unfortunately: > > https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html > >=20 > > 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 proc= essing > > it which it doesn't. the fact that it's included by Makefile.am somewh= ere is > > incidental. we have strong precedence that foo.in will produce foo, an= d that > > foo.am will produce foo.in. which doesn't happen here. > >=20 > > 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. > >=20 > > 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 ren= amed > > to "multilib.mk", but i don't have the willpower to shave that yak :p. > >=20 > > 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. > >=20 > > so if we've settled on ".mk" as the suffix, let's focus on the basename. > >=20 > > 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.mk". > >=20 > > i have seen "module.mk" once or twice. that might be slightly better > > than "local.mk". > >=20 > > so all things considered, i think "local.mk" is what we should use. >=20 > 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. >=20 > 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. >=20 > In the core kernel and lib subdirs all BSDs use files called Makefile.inc, > actually. >=20 > 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. -mike --n7s/dQvFFbn8Klxl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHwaXwACgkQQWM7n+g3 9YFqjQ//SoJCC6xRf7QmMVkTqvISjlERanSK1VUWlYr1KrfJoMpURdZhBN4jV8+1 lSmsSx4TMVEEPidovqxFBjE10DIXKfkCjD5e7dfqNLLoGKkUebkrxm4nebcVcI2G 5W5lTQuonmhOmY1mGvKCi+P2Nf4M7HLVVU7zKI6wUvEJUzzgreK1wESeWPHoxXnv 90IBZPrOu/XSmiloej0q/x78e5OX/BLpk/DOFbwMKITZdUM8OUwkdckIbU4ED6xV 0GvceDfk2/GYJYypag2d4ss0dssrBgZLOeUpHgSb8spBjqWMXTROQr8w4aMAq3gW CC6DAj2cG0/LGGDJRho47HXtWByXdOEJJERY05djylocN03ZRPnzTIka4iuSnfQD aE3p1plBMyMS9e9psYzLEy7KzC9LsEzccV1xNvKRgFW85o4uaQhlBSyH8DBPjGxG eGmkPOkhh/Gu9Nlyxv4qWSoiFDjziRc6s+PehALY8bnOYh91x/1Iy6p9vbIDdvl2 RIKCOMsJ1iN1XAkWfxJZxmlghJXG+VQLQfG8wNsNNeEDHXo4ni8ABSnz7Ydk9MLq OABakJQ607Q6Eb2JdAD87ryEn/GrFuRY5+JTJGxnp2NhwsDrDODWe3CMO/TIcpzJ Z63Yf3RRmFA64KcnBMtl1aPQ9lEfbRB1ahYMmv14XjcrTlZBowE= =roj8 -----END PGP SIGNATURE----- --n7s/dQvFFbn8Klxl--