Re: NEW: devel/libaio

On 05/02/18 03:03, Stuart Henderson wrote:
> 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.

Correct. To be clear, are you suggesting a different PKGNAME or a
different PKGNAME and library 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).
>

I'll just host it myself, save the headache.

~Brian