From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id 405533858D20 for ; Mon, 14 Feb 2022 16:49:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 405533858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qv1-xf33.google.com with SMTP id o5so15266310qvm.3 for ; Mon, 14 Feb 2022 08:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jEmCUH+gfsjKBpzHQWcOJ1r3sMNAEvzCoRwGQlsuy2U=; b=kERompgUD7H7cWz5O+b0cGQyuSyIBE1hni1B54TKL2tJ1kZHmJIwcaAS7ydUCBfePo 3LTTzmJSAGneZDUG4H9Y8I+gAGw4PuJvdFbdJfEYT4cKczxpFuFWr5PHFR1QZKi0wP4O HyfVcCy9FuPbcMq1wjVrRrIQKDYRvsxiekjLRwcxHkADqPMEci8ALHxGKUqTBE3WbXFw Yx3YB53TvfVg0LOz7q54EWSFf1SQcbGeBx/phxU07Gr5L2jJ1cZLpzskYvWOXWULV0L4 +ObkBC04OCkOlLaiIz/XvOdC/4L0obY34ALPco8PI91C1LYh90xxHibzajjLctKQYN9Y fbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jEmCUH+gfsjKBpzHQWcOJ1r3sMNAEvzCoRwGQlsuy2U=; b=qnnjJuTybnrFopykXAUGojAALwG921QUE8KmHJqZbLFnVrKwlWNC88+HJAmf/THC3L 5B7gfaFJcUlFXm5e6kR7dzDEz4kzWI8zoW1MvCO21EkxUOSh6NoDgzXU7I2rGpEGI8xU cb9cN+1RROFZYN6daCPg2uLs2kwhQDB5FRfyskSenfV2CL+NFVG+LdnftTjT5qjjnusg mAjq12fbUDCTUl/YqmaSg2B4/SJy9RwCM5UegBks+pDsLariCYT3JoxU1JT1L+iJRF1E IaE2dvTmWoRCDbzBzy5c7bhwUkREO/PuXGtR0tNHtX8Cz9m4iRug3JdxwrUr9gU/Mx0r +RgQ== X-Gm-Message-State: AOAM5312TLpNlCErwC4x2nDZ3BzP3ty+orkiB8hKgEvH38Rvo26YJ7rb 6jhcJdlWxcs6Y8qkG5oBKY6kYMr/dCoe7mu7C8pkNdivaQ== X-Google-Smtp-Source: ABdhPJyYTBHWRqO4K2Hs+u88JV/XBzMQvfpjj8ued6Iv2UF6yP1CfP+5s1FamZeBmp3WWE9NGkfHp/thQ9DAbZD4Nts= X-Received: by 2002:a05:6214:d0c:: with SMTP id 12mr377736qvh.118.1644857396386; Mon, 14 Feb 2022 08:49:56 -0800 (PST) MIME-Version: 1.0 References: <20220210055347.24825-1-vapier@gentoo.org> In-Reply-To: From: C Howland Date: Mon, 14 Feb 2022 11:49:45 -0500 Message-ID: Subject: Re: [PATCH] newlib: remove unused fenv flags To: newlib@sourceware.org X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 14 Feb 2022 16:49:59 -0000 On Sat, 12 Feb 2022 at 15:42, Mike Frysinger wrote: > 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 > files > > > > from the main--as if viewpathed--and this can also apply to the > makefile. > > > > (Does the machine directory totally replace the main branch > directory, or > > > > can it be supplemental? My impression was a viewpath model, which > can 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 > assembles > > > 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 > ones > > > with machine/$arch/*.o. > > > > 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 > Given the "take whole machine directory" model, it's probably best to take this patch as proposed. The thoughts about templating fenv to keep it easy for people not familiar with automake stuff, trying to avoid that aspect being an impediment to people taking on doing fenv for a new platform, can be handled separately by adding some separate notes. Craig