From owner-freebsd-arch@freebsd.org Fri Apr 27 23:36:59 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F67FFB473A for ; Fri, 27 Apr 2018 23:36:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E17C179EA6 for ; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9CBAFFB4739; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78844FB4738 for ; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0494A79EA3 for ; Fri, 27 Apr 2018 23:36:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id h143-v6so3861739ita.4 for ; Fri, 27 Apr 2018 16:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OQilJwz/KY6OrPOoh6RnDlCeZbvskzYVMnHY2J7eITI=; b=wSSgEPyn2oialAb59LfZVuYo9yRb5xxTxZ0xImZhtdpkIWdO3THvCJyK4MXh7e0GdG t8rJeDUCivDGumFDiWzK2ZmP+DBPr/hESs6xiGiRyWRVahbIy1MXt2fwlmvoHZa+3b2C /nKHoujjhM/cQ60i0H3/cA+CSVM3Pmz+/oYFKW47Wv6zoq2e5i3fbD4ObdeNp0eeHeC3 GtM49HzTA+EUildJ1XbKzhYxrn4nrVDP6YoXAzx7ZTT6n0Z28ENePrInbnhEe6gqAqgS fkJgPQELbywefvP73g8rpQM2TKhaTZGzeSmi4EZbdPOHMtE2/0uCC+bb98Z//AxAkEoQ Bx8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OQilJwz/KY6OrPOoh6RnDlCeZbvskzYVMnHY2J7eITI=; b=rVP+a6JPCj35OC+SuFoege6XEciopzcVl0k0qmoTSz+lhTlivoOQ6l61XhdnSIpisn Q3M6X1IaG9CU2wOvr9zBCmnoEZur/4yDILp2Ljj1Z2yLLhz2yl8wVdcU8wZ8HswEYfv1 SMKhOKn0W2TXN3L7OKz4zYlVW7HAR3Ky1hQZN2XvHxOWKVI/PUVr14t1fX0E3bH0Ye2a vRzm13MwZS96kQlSk91Jpl6m4a9ATyGrCSPsFVeMIN0Co6Tl91gv7U1NVDfGwIEhMXVk igY9NLRPXUImrhVuqCTgQgZxx7d90b7R7+0FmMyIAc7CeMVYUeuZ9Yd5Vasce0XPhD/3 iOsg== X-Gm-Message-State: ALQs6tAnfwuysYQsGLuuz1Q0VkuhxTT20cDlBpGEO39b8tItK0bXfjTh SqKCzt/dQPfoPjJ5AGJ2VXS37FJHyDNEbKMDg90Utw== X-Google-Smtp-Source: AB8JxZpNCGqFMi9C5x34vat/9ww6qy0+rDj/ur0uMXMb9aHM80iNgQKfMJdrPBObGfWza081TT18rQwhFdTweDUlgto= X-Received: by 2002:a24:e983:: with SMTP id f125-v6mr4002923ith.36.1524872217152; Fri, 27 Apr 2018 16:36:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 16:36:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <1711113.VelFtdTVS7@ralph.baldwin.cx> References: <1711113.VelFtdTVS7@ralph.baldwin.cx> From: Warner Losh Date: Fri, 27 Apr 2018 17:36:56 -0600 X-Google-Sender-Auth: fBAjKVvAfHoBUGgLeypa1Av5NSA Message-ID: Subject: Re: LIBC_SCCS To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 23:36:59 -0000 On Fri, Apr 27, 2018 at 4:19 PM, John Baldwin wrote: > I suspect no one cares, but for whatever reason our current handling of the > LIBC_SCCS macro in some of our libraries annoys me. In theory it seems > like > LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley > are included in libc's sources when libc is built. (Similar to how macros > control the behavior of __FBSDID().) However, we use an odd construct in > the tree. First, we define LIBC_SCCS by default in the CFLAGS of various > libraries (libkvm, libutil, libthr, libc, etc.) which in theory would > enable > the IDs, but then we explicitly wrap them in #if 0, e.g.: > > #if defined(LIBC_SCCS) && !defined(lint) > #if 0 > static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93"; > #endif > #endif /* LIBC_SCCS and not lint */ > > I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and > perhaps the lint baggage) but then remove it from the default CFLAGS to > preserve the existing behavior by default. Does anyone else care if I do > this? > I'm cool with it. Why not do __SCCS_ID( "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93");? I don't know if we need a separate #ifdef for each SCCS_ID subtree in our build. Either it's there, or it's not. Default: not. It would also let us put them in separate sections ala our freebsd id macros. I'm slightly against removing it altogether, though I can see a good case for it. I have a visceral reaction that puts me in the 'against complete removal' camp, but only just. Warner