Add script to setup codesigning on macOS

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hello, 

I’m interested in setting up a macOS build of GDB on conda-forge ([1], [2]) and it seems that in order to do it the codesigning procedure would have to be automated, i.e. entirely command-line driven. 
The LLDB project already has a script doing exactly that [3], and I was thinking of adding such a script to the conda-forge GDB feedstock. 
However, I thought it could be a good idea to add it directly to the GDB repository. Would a patch adding such a script be well received  ?

Thanks,
Philippe Blain.

[1] https://conda-forge.org
[2] https://github.com/conda-forge/gdb-feedstock/issues/7
[3] https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
From gdb-return-47330-listarch-gdb=sources.redhat.com@sourceware.org Thu Dec 12 06:17:31 2019
Return-Path: <gdb-return-47330-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 89410 invoked by alias); 12 Dec 2019 06:17:30 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 89401 invoked by uid 89); 12 Dec 2019 06:17:30 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=investigations, H*MI:sk:838snjb, HX-Languages-Length:1149
X-HELO: eggs.gnu.org
Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Dec 2019 06:17:29 +0000
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60467)	by eggs.gnu.org with esmtp (Exim 4.71)	(envelope-from <eliz@gnu.org>)	id 1ifHmw-00012L-5b; Thu, 12 Dec 2019 01:17:26 -0500
Received: from [176.228.60.248] (portE52 helo=home-c4e4a596f7)	by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)	(Exim 4.82)	(envelope-from <eliz@gnu.org>)	id 1ifHmv-00018P-NT; Thu, 12 Dec 2019 01:17:25 -0500
Date: Thu, 12 Dec 2019 06:17:00 -0000
Message-Id: <838sni9ifm.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Christian Biesinger <cbiesinger@google.com>
CC: gdb@sourceware.org, palves@redhat.com
In-reply-to:	<CAPTJ0XH8UY-DCwjRaofxy3r0j1xnCKL93yc1QDb_jesiKYw-uw@mail.gmail.com>	(message from Christian Biesinger on Wed, 11 Dec 2019 17:59:39 -0500)
Subject: Re: Renaming .c files to .cc?
References: <CAPTJ0XEXR2Kb9CU1j17g9VE9fU07xsWHJSk4QiD1ma47F1TSsA@mail.gmail.com> <838snjbkqm.fsf@gnu.org> <CAPTJ0XH8UY-DCwjRaofxy3r0j1xnCKL93yc1QDb_jesiKYw-uw@mail.gmail.com>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-IsSubscribed: yes
X-SW-Source: 2019-12/txt/msg00013.txt.bz2
Content-length: 1126

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 11 Dec 2019 17:59:39 -0500
> Cc: gdb@sourceware.org, Pedro Alves <palves@redhat.com>
>
> > Not every Git command has a --follow option, so renaming files does
> > have disadvantages in that area.
>
> Do you have a specific command in mind that doesn't? I haven't come
> across that yet myself.

Are you saying that every Git command supports that option?  I don't
think so.

And even those who do support it impose limitations when it's used.
For example,

  $ git log file1 file2 ...

works, but

  $ git log --follow file1 file2 ...

fails with an error message.  So many important forensic
investigations limit you to single files when using --follow.

> > Also, even with --follow, Git's tracking of renaming is heuristics,
> > so it can fail.
>
> Technically correct, but not an issue in practice when files are being
> renamed without changes, like they would be here.

That's not guaranteed, because several files with similar contents can
dupe the heuristics.

Anyway, like Pedro said: the reasons for being in the "rather not"
camp are not strong.