From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 143DA3857C7B for ; Tue, 25 Jan 2022 12:27:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 143DA3857C7B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643113655; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=dAneZAmQUYSxi+fzJRK9hM5SJ1lIP0UpUyrTT9Ql+YE=; b=AjsnysQ+3vwEoJowitU1nTv8vnQ846VXWQHfTcIMuJSV/RlZJ1QqXwVMWznM3vabib1hgv A2isRsVf6V0LVCz2fMFIkEC09FIlXKbgbfedEO7fzpbFhuBeyaigklfT59JpMNbYEhLi58 pNq5T5hGxY7TL+mS1L9baCYetdRfVpY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-CzQivguuNga9qWAZMQi_3g-1; Tue, 25 Jan 2022 07:27:27 -0500 X-MC-Unique: CzQivguuNga9qWAZMQi_3g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1ADF01083F64 for ; Tue, 25 Jan 2022 12:27:26 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-112-15.ams2.redhat.com [10.36.112.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DF197108BD2D for ; Tue, 25 Jan 2022 12:27:25 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 64DFCA80733; Tue, 25 Jan 2022 13:27:24 +0100 (CET) Date: Tue, 25 Jan 2022 13:27:24 +0100 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH] newlib: merge iconvdata into top-level Makefile Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <20220122060458.7539-1-vapier@gentoo.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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 12:27:37 -0000 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 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.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 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. Corinna