From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 4FB233858010 for ; Sat, 12 Feb 2022 20:42:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4FB233858010 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 D889A343298; Sat, 12 Feb 2022 20:42:05 +0000 (UTC) Date: Sat, 12 Feb 2022 15:42:09 -0500 From: Mike Frysinger To: C Howland Cc: newlib@sourceware.org Subject: Re: [PATCH] newlib: remove unused fenv flags Message-ID: Mail-Followup-To: C Howland , newlib@sourceware.org References: <20220210055347.24825-1-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TAE9htNCzi9cJe9M" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Sat, 12 Feb 2022 20:42:07 -0000 --TAE9htNCzi9cJe9M Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11 Feb 2022 11:10, C Howland wrote: > On Fri, 11 Feb 2022 at 05:09, Mike Frysinger wrote: > > On 10 Feb 2022 14:18, C Howland wrote: > > > First, would be if a machine directory can override just some fi= les > > > from the main--as if viewpathed--and this can also apply to the makef= ile. > > > (Does the machine directory totally replace the main branch directory= , or > > > can it be supplemental? My impression was a viewpath model, which ca= n be > > > supplementary or replace all.) If I'm wrong about this, no problem, = no > > > objection for this specific reason. > > > > assuming "viewpathed" means "VPATH in the makefile", then no, that's not > > how newlib works. that is how glibc works, so maybe you're thinking of= that. > > newlib compiles all objects in all subdirs in isolation. it then assem= bles > > the final libm.a/libc.a in a specific order (with the machine dir last). > > so it adds fenv/*.o to libm.a by basename, then replaces any existing o= nes > > with machine/$arch/*.o. >=20 > Yes, I meant as in VPATH in a makefile with individual file granularity. > So, yes, I was thinking not the right thing for newlib, sorry for > conflating Newlib with other things. i'm not sure pulling off a vpath build in newlib would be that easy. or at least, it would require writing more custom logic that we get for free when we use automake. at this point, with the size of newlib, i'm not sure we would gain that much. yes, we double compile the common code, but since the files are small and so few, so eh. > OK, neither you nor Joel think templating for the makefile to be of much > use, that makes a majority in comments so far and I'll go along. (Since > fenv is special and tricky I think we would be better off with better > instructions for this one particularly, as it would encourage/help people > to add new targets.) > I agree that these specific compiler options do need care taken. But > that's part of the reason they're good examples for the fenv environment, > as that's a tricky subject that needs special attention and might need > things like them. But at the same time I agree that they are also for the > same reason potentially dangerous to suggest. with the new unified non-recursive automake patch i posted, it actually would be feasible to put compiler settings in one makefile and have them apply to others (by declaring the flags by filename). but the question of whether we even want to do that in the first place is still open. -mike --TAE9htNCzi9cJe9M Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIIG6EACgkQQWM7n+g3 9YFG2BAAs8uIsYyN1E7dpdU8cFaQpFz2+xa8oYh62YRKLWNpw+Kw68ub2+9fZN/k 2yylWrxNsFp9Vd+SkWROZkrVqbzflo4R4ziHI1ksM/CGisEhAwt4aeZW9h6W8REt RmIB2rBHl7bGmkOWGyoI0+IZwBiiHlIBDJ9MCUWDSgGAcUiWq09fedCnz1vuid88 ci/NUhLZaA/rRLstsGmXn5fgDICFK0e/48lR1U7ypLEQaBa3iZ9x8xRFcmiOfaWc UbpkGpHia9nBNgQCVhA9bPwM/wt+1dXCUCyPZ6X0Sop45JB8C0PM1BiZQ4RZpt3C 0ubwVwh49/1UV45SBIiX6bUmVc5ahEf1i44VYRwsBm0kCh/KNv59u0TiNgvY/UjU mrIQBDKOEvrU4LIJUvdeP5uBWryUKHFDXHlbwC8nzHv1Wgl962dygNenda1m/rUH qLPbm1AOLd0XlaGyA8njV/9yD1mfrS6170clzoPX0oq32aep02x17OloRtMkYj5e 7mo5hgwInWiVijQi4w008YGQC8eft+uPCStNZ+c8SWoD8qVRgsc+C4kz9hZp8Ryb KljSVsPv+wmJIDlpJjt2J+wByqty8cfs7A76CnPGUYAbVegRbXAl3C0UsenIIHxS AHoAgkL1ze9oWdfgSmG9MO+aBYF3dsh1rjfU3wtu56AaIbtQCDw= =kUSO -----END PGP SIGNATURE----- --TAE9htNCzi9cJe9M--