From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id CFA7D3857C42 for ; Sun, 6 Sep 2020 11:52:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CFA7D3857C42 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id F1C141E509; Sun, 6 Sep 2020 07:52:36 -0400 (EDT) Subject: Re: [PATCH] Rename block.{h,c} to gdb-block.{h, c} To: Saagar Jha , gdb-patches@sourceware.org References: From: Simon Marchi Message-ID: Date: Sun, 6 Sep 2020 07:52:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2020 11:52:38 -0000 On 2020-09-05 10:21 p.m., Saagar Jha wrote: > GDB doesn’t build with newer SDKs because its block.h conflicts with macOS’s Block.h. This patch resolves the issue by renaming GDB’s files. > Hi, Can you include in the commit message: - which SDK are we talking about (for the non-initiated to macOS) - the relevant versions (macOS, SDK) Renaming our file is a little bit annoying, but I don't see a better solution. We could change our includes to be "./block.h" or "gdb/block.h", but sooner or later someone will add back a "block.h" include. It will silently break macOS because we don't have CI for that, and it will take somebody building GDB on macOS to notice and fix it. In your ChangeLog entry, drop the "gdb" part of the filenames, so that they are relative to the ChangeLog file itself (Makefile.in instead of gdb/Makefile.in). Simon