From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46041 invoked by alias); 25 Nov 2016 18:44:23 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 46029 invoked by uid 89); 25 Nov 2016 18:44:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=*BSD, *bsd, claim X-HELO: mailbackend.panix.com X-Gm-Message-State: AKaTC01C3P5OG2sWAdb6HusXp3hXxKeGsnqKYv08V4qFy9va7CjtoZ3w4oqMN+OjwgnLDoE9zyuAQhw73ZoPvA== X-Received: by 10.28.150.75 with SMTP id y72mr9513071wmd.47.1480099449154; Fri, 25 Nov 2016 10:44:09 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <662a011c-f3f8-1c43-9b98-542d499b3dca@redhat.com> References: <9426ee75-3e45-6cde-b659-567398007a32@redhat.com> <1d0c74a4-965d-be13-6945-5af479eecbdc@panix.com> <662a011c-f3f8-1c43-9b98-542d499b3dca@redhat.com> From: Zack Weinberg Date: Fri, 25 Nov 2016 18:44:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] extras: New test/build infrastructure To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00940.txt.bz2 On Fri, Nov 25, 2016 at 12:45 PM, Florian Weimer wrote: > On 11/25/2016 05:14 PM, Zack Weinberg wrote: >> >> Can I ask why the new directory is called "extras"? That makes it sound >> like a home for extra features that we want to provide but not in the >> core C library. Something more obviously internal-use and >> build/test-related would be better, I think. > > I plan to use bits of it for fixing localedef bugs and contributing Fedora > changes upstream. Those bits would then end up in installed binaries. > > The immediate need is for testing only and generic test support code > (container setup, a fake DNS server implementation, and so on). So maybe "support/" or "build-test-support/"? >>> +libextras-static-only-routines := $(libextras-routines) >>> +# Only build one variant of the library. >>> +libextras-inhibit-o := .os >>> +ifeq ($(build-shared),yes) >>> +libextras-inhibit-o += .o >>> +endif >> >> This doesn't look right if the goal is to build only the .a version of >> the library. > > Could you clarify what worries you? If there's just one variant, it has to > be PIC, unless it's a static-only build. I may well not understand what this combination of -static-only-routines and -inhibit-o does, but what it *looks* like it does is disable generation of .os (PIC) object files unconditionally, and if shared libraries are enabled, it also disables .o (static) object files. I would expect this to wind up either not working at all, or producing only a *shared* library, or possibly only a profiling library! Also I don't know why this code would need to be PIC. >> This library is _not_ part of the implementation and should not be using >> __ names. And I'm not sure it ought to be using features.h either. > > is needed for __BEGIN_DECLS. Including would be > even more extreme, I think. Honestly I think sys/cdefs.h has a better claim to be a public interface than features.h, since it exists on *BSD (and does in fact define compatible __BEGIN_DECLS/__END_DECLS there too: see https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h) zw