rename patch to patcz

[smanders]

on macOS, the latest release of this project (v2.7.6.3), uses the "system" patch instead of the one built https://github.com/externpro/patch/blob/v2.7.6.3/CMakeLists.txt#L45-L55

if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
  string(JOIN "\n" EXT3
    "if(CMAKE_SYSTEM_NAME STREQUAL Darwin)"
    "  find_package(Patch REQUIRED BYPASS_PROVIDER)"
    "  if(Patch_FOUND)"
    "    set(PATCH_EXE \${Patch_EXECUTABLE})"
    "  endif()"
    "endif()"
    ""
    )
endif()

this was an attempt to get around the macOS Gatekeeper issue detailed here externpro/externpro#160 (comment)

however, the "system" patch on my development MacBook is an "older" release

$ which patch
/usr/bin/patch

$ patch --version
patch 2.0-12u11-Apple

and some of the exdlpro projects that "move" or "rename" or "introduce" a new file as part of the patch are failing -- an issue that I've dealt with before! smanders/externpro#295 (comment)

the solution then (and now) is to use GNU Patch >= 2.7

You need GNU Patch >= 2.7. From their News page (https://savannah.gnu.org/forum/forum.php?forum_id=7361) about 2.7:

Support for most features of the "diff --git" format, including renames and copies, permission changes, and symlink diffs. Binary diffs are not supported yet; patch will complain and skip them.

the unexpected behavior is that it seems executables that are part of other externpro developer packages (bzip, node to name a couple) are able to run after being extracted via externpro cmake without Gatekeeper flagging them...

so maybe something else about patch was causing it to be flagged? I wondered if macOS was like Windows (or at least the Windows behavior I saw years ago when I first started developing externpro...) and if I simply renamed patch to patcz then it wouldn't be flagged -- see https://superuser.com/questions/1720717/bash-patch-exe-permission-denied-how-to-turn-off-security-regarding-patch-i

but downloading the build artifacts from this pull on macOS still resulted in Gatekeeper stopping it from executing ./patch --version

however, I decided to attempt to run ./bzip --version from the downloaded and extracted location just to double-check that it does, in fact, work

$ _bld-Darwin/_deps/bzip2-v1.0.8.2-Darwin-arm64/bin/bzip2 --version
bzip2, a block-sorting file compressor.  Version 1.0.8, 13-Jul-2019.
   
   Copyright (C) 1996-2019 by Julian Seward.
   
   This program is free software; you can redistribute it and/or modify
   it under the terms set out in the LICENSE file, which is included
   in the bzip2 source distribution.
   
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   LICENSE file for more details.
   
bzip2: I won't write compressed data to a terminal.
bzip2: For help, type: `bzip2 --help'.

and then I attempted the same thing for patch --version

$ _bld-Darwin/_deps/patch-v2.7.6.3-Darwin-arm64/bin/patch --version
GNU patch 2.7.6
Copyright (C) 2003, 2009-2012 Free Software Foundation, Inc.
Copyright (C) 1988 Larry Wall

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Larry Wall and Paul Eggert

so, for some strange reason, if you download and extract the patch build artifacts manually, Gatekeeper will flag it... but if you download and extract the build artifacts via externpro cmake, it appears that it "just works" and Gatekeeper doesn't flag it -- without all the notarizing and code signing that I thought might be required!

I'm going to keep the rename, though, just so it's consistent on all platforms... and so patcz is uniquely named for externpro's patch project