Message ID | 20140314200309.83A247449E@topped-with-meat.com |
---|---|
State | Committed |
Headers |
Return-Path: <x14307373@homiemail-mx21.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx21.g.dreamhost.com (caibbdcaaahb.dreamhost.com [208.113.200.71]) by wilcox.dreamhost.com (Postfix) with ESMTP id 2433C3600C8 for <siddhesh@wilcox.dreamhost.com>; Fri, 14 Mar 2014 13:03:18 -0700 (PDT) Received: by homiemail-mx21.g.dreamhost.com (Postfix, from userid 14307373) id CCBBEC43262; Fri, 14 Mar 2014 13:03:17 -0700 (PDT) X-Original-To: glibc@patchwork.siddhesh.in Delivered-To: x14307373@homiemail-mx21.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx21.g.dreamhost.com (Postfix) with ESMTPS id 94A1AC6044D for <glibc@patchwork.siddhesh.in>; Fri, 14 Mar 2014 13:03:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:content-type :content-transfer-encoding:from:to:subject:message-id:date; q= dns; s=default; b=pQVlUFnTBxvdpfx5BzG5EowuUCefCu/ztYJ8Q00k1+SHgp nSfWGiHjrM6/TYw452ePYPk6XBzl1EfC/U997dSNpbXQrQ7Wv443rF9cUHKMZ66E qUpdCU0xSiUtZ3HyhQyDWrGenFHf9YfdUqWyot776sHO87mIdatX94rB+TJyQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:content-type :content-transfer-encoding:from:to:subject:message-id:date; s= default; bh=/iOCD2EcMy02OyI8b178wxCX02Q=; b=VJTOm5b5A3BmVxH0Twep tpLTcnASzYnVOJ59gdZosHkCFeUVmzB+urE3MZVpWmhfncpsxC+D8dTGoxf8cq4m vciqbrgjYphJMu18ykzaLmslBsXwijB36S2u/1mRZNMUudHcDYL5PbZtHKiaOYPv qD3l23nxKKDsb9gd0UAxGOQ= Received: (qmail 3544 invoked by alias); 14 Mar 2014 20:03:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-glibc=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 3534 invoked by uid 89); 14 Mar 2014 20:03:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: topped-with-meat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath <roland@hack.frob.com> To: "GNU C. Library" <libc-alpha@sourceware.org> Subject: [PATCH roland/mman-linux] Move bits/mman-linux.h out of sysdeps/unix/sysv/linux/. Message-Id: <20140314200309.83A247449E@topped-with-meat.com> Date: Fri, 14 Mar 2014 13:03:09 -0700 (PDT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Rt9WckWK c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=4KPrJs8tsEEA:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=0Y3u0BwCnMsBKFZNXxgA:9 a=CjuIK1q_8ugA:10 X-DH-Original-To: glibc@patchwork.siddhesh.in |
Commit Message
Roland McGrath
March 14, 2014, 8:03 p.m. UTC
I'm working on a non-Linux port (NaCl) that uses the Linux bits for various things, including the bits/mman.h bits. It reduces duplication if I can just use bits/mman-linux.h, but as things stand that file is only available in Linux configurations. It's a bit nonobvious that sysdeps/unix/sysv/linux/Makefile (and soon sysdeps/nacl/Makefile) has to add bits/mman-linux.h to sysdep_headers though the header itself is outside of sysdeps/unix/sysv/linux/. But I think that wrinkle is preferable to winding up with manual duplication. If people think this is a bad idea, I can always do something more hokey in the NaCl port to copy the source file during the build or something. Opinions? Thanks, Roland 2014-03-14 Roland McGrath <roland@hack.frob.com> * sysdeps/unix/sysv/linux/bits/mman-linux.h: Moved to ... * bits/mman-linux.h: ... here.
Comments
On 03/14/2014 04:03 PM, Roland McGrath wrote: > I'm working on a non-Linux port (NaCl) that uses the Linux bits for various > things, including the bits/mman.h bits. It reduces duplication if I can > just use bits/mman-linux.h, but as things stand that file is only available > in Linux configurations. > > It's a bit nonobvious that sysdeps/unix/sysv/linux/Makefile (and soon > sysdeps/nacl/Makefile) has to add bits/mman-linux.h to sysdep_headers > though the header itself is outside of sysdeps/unix/sysv/linux/. But I > think that wrinkle is preferable to winding up with manual duplication. > If people think this is a bad idea, I can always do something more hokey > in the NaCl port to copy the source file during the build or something. > > Opinions? I'm happy with such a change. A perfectly structured set of headers is the enemy of the good. I think reducing duplication of these constants is a good thing. Every other way I can think of organizing the header, include_next, or something else, just looks uglier than moving the header. So your solution seems like the most reasonable. On request. Add enough comments that we know why this file is there so someone reading either Makefile's or the header itself knows why it's not where it should be. Cheers, Carlos.
> I'm happy with such a change. A perfectly structured set of headers is the > enemy of the good. I think reducing duplication of these constants is a good > thing. I merged it. > Every other way I can think of organizing the header, include_next, or > something else, just looks uglier than moving the header. So your solution > seems like the most reasonable. I also had a hack where sysdeps/.../Makefile just copied the source file to the build directory. That works well enough and avoids nastiness inside the file itself. But it's less clean than moving the file. > On request. Add enough comments that we know why this file is there so > someone reading either Makefile's or the header itself knows why it's > not where it should be. I forgot about this request before I pushed the change. I'll add some comments now. Thanks, Roland
On 03/18/2014 05:52 PM, Roland McGrath wrote: >> Every other way I can think of organizing the header, include_next, or >> something else, just looks uglier than moving the header. So your solution >> seems like the most reasonable. > > I also had a hack where sysdeps/.../Makefile just copied the source file to > the build directory. That works well enough and avoids nastiness inside > the file itself. But it's less clean than moving the file. It always irritates me when other build systems do this as it makes it harder to understand the entirety of the source without having a build directory. At present we do a pretty good job of keeping the source structured such that you can read it and understand what it should do. >> On request. Add enough comments that we know why this file is there so >> someone reading either Makefile's or the header itself knows why it's >> not where it should be. > > I forgot about this request before I pushed the change. > I'll add some comments now. Thanks. Cheers, Carlos.
diff --git a/sysdeps/unix/sysv/linux/bits/mman-linux.h b/bits/mman-linux.h
similarity index 100%
rename from sysdeps/unix/sysv/linux/bits/mman-linux.h
rename to bits/mman-linux.h