Go or Rust Packages?

[Corinna Vinschen]

On Feb  4 00:14, Mark Geisert wrote:
> Brian Inglis wrote:
> > On 2022-02-02 02:44, Corinna Vinschen wrote:
> > > On Feb  1 21:22, Adam Dinwoodie wrote:
> > > > The upstream fzf package moved from Ruby to Go some time ago.  I had
> > > > vague but noble intetions to try to maintain a fork on the basis of the
> > > > last version of the Ruby code, but never managed anything useful.  In
> > > > that context, I expect it's time that I officially throw in the towel,
> > > > and mark fzf as orphaned.
> > > > 
> > > > The existing build still works, and I don't think there's likely to be
> > > > any crass security problems or anything like that.  But there's no
> > > > longer any upstream support, and I clearly don't have the capacity to
> > > > properly maintain it solo.
> > > > 
> > > > I'm not quite sure what the process is here, but I suspect it's just a
> > > > case of someone with the appropriate access making an update to
> > > > https://cygwin.com/cygwin-pkg-maint
> > 
> > Anyone know of anyone trying to build Go or Rust on Cygwin?
> I made some progress with Go on Cygwin a couple years ago, but had to give
> up because it required more time than I could give it.  I got about 1/3 of
> the way through it.  The last straw was its need for syscall?() and Cygwin
> not having those functions (or a need for them).  It was a lot of looking
> for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)".  The goal
> still tantalizes though...

You might be better off writing a syscall layer which translates the
expected syscalls into standard POSIX API calls.  Cygwin could even
provide that in the long run.

Ages ago we discussed converting cygwin1.dll to cygwin2.dll and only
export a syscall interface with any arbitrary libc on top (e. g. glibc),
but that would have been a near full re-implementation of Cygwin, so we
buried the idea.  However, providing a syscall layer on top might be a
nice extension.


Corinna