Closed mattpolzin closed 1 month ago
I didn't make this clear above, but I will most likely be able to do some of the work to enable this support if desirable so I'm not creating an issue to offload work onto you, just to discuss the desired approach. If you do the work, that's great by me, but if not, I'll plug some time into the problem at some point.
Thanks for raising this issue and your offer to help with this. Indeed, this kind of feedback is highly appreciated, since multi-platform support is most definitely a goal (for the posix library). For the time being, I'd like to keep Errno
a simple wrapper around Bits32
, so testing for __GLIBC__
during codegen would be the preferred way forward.
This shouldn't be too hard to change. If you happen to have a list of the POSIX errors that should work on most platforms, I can certainly do this myself (or I can come up with such a list myself).
I do have that list and it's definitely not a difficult change (I made it once already :smile: ): https://github.com/mattpolzin/idris2-linux/blob/glibc-patch/posix/codegen/error.c#L108..L145. I can see that your refactor could be applied to my branch with a couple of find-replaces for the most part so if you don't fix this yourself that's probably what I'll do in the next week or so and put a PR up for you to look at.
I was tinkering with the
posix
package (realizing it is still in heavy development, of course) and the first thing I discovered that will make it fail to compile on some platforms (looking at you, macOS) is that not all of the defined error number macros are available on all POSIX systems. Linux appears to have an especially large number of extra errors defined above the minimum.I wanted to raise an issue to discuss with you because I can think of at least two ways to handle this (assuming multi-platform support is a goal).
For one, we could just omit the extra error definitions when not relevant at compile time. Fortunately, we don't need to even know the operating system, we can check for whether
__GLIBC__
is defined at compile time to conditionally define errors in your gencode scripts. This is a strategy I used as a proof of concept (albeit before the most recent refactor toerror.c
and so not mergable at the moment). I think adjacent to this strategy would be to define them all the time but for non-glibc compilation set them all to an out of the way dummy value.Alternatively, I could imagine a structural distinction in the actual Idris code a la the split between
Signal
andPosixSignal
in base. That's nice because it gives Idris code something concrete to understand some of the codes simply not being viable sometimes and, of course, Idris code can make decisions based on what OS it is running on more easily than it can make decisions based on what environmnet it is being compiled on (the latter of which is not possible without using code-generation).