On 2018/05/02 00:50, Brian Callahan wrote: > Hi ports -- > > On 01/05/18 19:19, Brian Callahan wrote: > > Hi ports -- > > > > Attached is a new port, devel/libaio. libaio is a port of the DragonFly > > BSD userland POSIX asynchronous I/O routines to OpenBSD. > > > > When updating lang/flang earlier today, I realized that there are a > > dozen patches that work around the fact that OpenBSD doesn't have an > > aio implementation. Having to maintain a number of patches for flang > > already, reducing that number is a great help. > > > > It turns out that DragonFly BSD has a minimal but standard-compliant > > userland implementation of aio. So I did a quick and dirty port of it. > > flang is very happy with it. > > > > According to POSIX, these routines belong in librt. I'm not opening > > that can of worms. I named the library libaio. That way, you have to > > specifically seek it out to use it. The good news is that a quick > > perusal of the ports tree didn't turn up any port other than flang that > > has patches that work around not having aio. At this rate, it'll be > > maybe 2038 by the time another port needs the library anyway. > > > > --- > > pkg/DESCR: > > libaio is a port of the POSIX asynchronous I/O library from DragonFly > > BSD to OpenBSD. > > > > This version of AIO is aimed at standards compliance; it is not aimed at > > either reasonability or performance. It merely wraps synchronous I/O > > routines. > > --- > > > > Builds and passes some rudimentary tests on both amd64 and armv7. Makes > > flang happy on amd64. > > > > OK? > > > > ~Brian > > > > I'd still like to get this in. New tarball attached. This will very much > help keep flang updated.
If I understand correctly this is for posix AIO support - aio_read, aio_write, aio_fsync etc, rather than emulating the functions in Linux's libaio (wrapper for syscall-based implementation - io_setup, io_submit, etc). If that's right, I think it would be better to pick a different name. Please either create a release in github and upload a tarball as an asset (giving a stable tarball), or if you're going to stick with the on-the-fly autogenerated one, use GH_* instead of manually setting MASTER_SITES/WRKDIST/etc (and be prepared to cope if github updates their software stack in a way which changes the file).
