Closed BogdanTheGeek closed 1 year ago
Looks good so far, but i guess i gotta ask some mac people. @mattnite, aren't you running a mac?
Wow, crazy timing, I was just looking at this yesterday and was sad about the lack of macOS coverage. @MasterQ32 I pulled it down locally and confirmed that it runs smooth.
I think the config for .macos
and .linux
could be joined by passing std.os.darwin
or std.os.linux
to a more generic UNIX function.
Also, the readme probably needs updating.
@MasterQ32 let me know if you want me to change anything before merging(after people have tested it ofc).
PS: would @cImport
create a dependency for libc on linux and windows as well, or do they get stripped out at link time because the code is unreachable?
I've unified the unix-like configuration. Could someone test it on linux to make sure i didn't break anything :)
I'll try to test on Linux later today. I wonder, is there any way to get usb info? Like I'd like to know which one is made by raspberry pi for example. Or is that more of a libusb thing?
I'll try to test on Linux later today. I wonder, is there any way to get usb info? Like I'd like to know which one is made by raspberry pi for example. Or is that more of a libusb thing?
Yeah, also macOS has a terrible way of exposing the source of the tty, so maybe better handled by a higher level library.
I'll try to test on Linux later today. I wonder, is there any way to get usb info? Like I'd like to know which one is made by raspberry pi for example. Or is that more of a libusb thing?
I guess that's part of another PR :) If you guys can test and say it's green, i'll merge!
@MasterQ32 I've tested it on arch linux, all tests pass.
Added support for macOS. All test pass on macOS. Only
/dev/cu.*
ports work properly. Requires linking against libc to accesstcflush()
, but I believe that is the default for macOS.PS: Please review this carefully as I am a total novice in Zig(I mostly do embedded C).