[PATCH] gsed.cfg: Add check for gsed

[Ryan Long]

On 10/4/2022 4:31 PM, Chris Johns wrote:
> On 5/10/2022 12:52 am, Ryan Long wrote:
>> It looks like gcc checks for gsed if sed is not the GNU version.
> Thanks for checking this.
>
>> I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
>> MacOS, but that's because it fails to build gsed.
> Homebrew complicates your work. I make sure my test Macs have never had Homebrew
> or Macports installed. When I played with this a long time ago the install
> prefix was /usr/local and after a while I found I had no idea what was installed
> and what was provided by the OS and if the base OS versions were overwritten. I
> believe Macports is not doing this these days (if it ever did) but I have not
> looked.

On the m1 macs, Homebrew installs under /opt/homebrew/bin. The prefix 
for Intel macs is /usr/local, so I assume anything installed would be 
under /usr/local/homebrew/bin.

I don't know when the packages in Homebrew may overwrite the programs 
used by the systems, but at least in the case of gsed, it didn't 
overwrite the system's sed.

>
>> The error is "machine `arm64-apple' not recognized".
> Does the GNU sed upstream project have a fix?

I looked into how Homebrew builds it. All that they do is

   def install
     args = %W[
       --prefix=#{prefix}
       --disable-dependency-tracking
     ]

     args << if OS.mac?
       "--program-prefix=g"
     else
       "--without-selinux"
     end
     system "./configure", *args
     system "make", "install"

I experimented with the building of gsed with the RSB. I just removed 
the --host flag, and I was able to get around the error. However, it 
then reports

sizes: gsed-4.8-arm64-apple-darwin21.6.0-1: 16.874MB (installed: 0.000B)

>
>> So I added this check to get around that, and it built successfully.
> Sorry, I see Homebrew and Macports as user options and not a project option. We
> need repeatable builds and not builds based on a local checkout of some packages.
>
> Chris