jlrs
jlrs copied to clipboard
Taaitaaiger
MacOS support
I guess jlrs is not compatible with MacOS, at least as far I could see from the source code. Since MacOS comes with a relatively similar toolset to that of Linux, I'm guessing it might not be too difficult to support MacOS as well.
I was wondering if this was on the roadmap, or what I could do to help support MacOS for jlrs.
Hi, The only reason it's not supported yet is because I don't own any Apple devices to test if things work. I'm definitely open to adding support, I expect very little has to change (handle it in jl-sys's build.rs, document how to build on MacOS, and enabling CI if possible). It might be that the Linux instructions work for MacOS, but I'm not 100% sure.
If you're willing to help out, I appreciate that a lot! I think the best starting point is to change #[cfg(target_os = "linux")] to #[cfg(any(target_os = "linux", target_os = "macos"))] in build.rs and try to follow the build instructions for Linux.
I own a mac device, and definitely willing to help out.
I'm experimenting with MacOS support here: https://github.com/nikhilmitrax/jlrs
I wanted to make it slightly more ergonomic, so instead of parsing (or expecting) JULIA_DIR, I'm parsing the Julia path off of the command line.
The code, as it exists in that fork, sort of works, except it required DYLD_LIBRARY_PATH to be set. I'll try to figure out why that is, and maybe send an MR your way with support added.
The problem with using which is that it only works if julia is installed in a default location, I personally install it in my home directory and that would break as a result. I'd prefer to keep supporting JULIA_DIR to allow non-standard installation locations, but I do think it's fair to use which to try and find Julia if JULIA_DIR isn't set. I'm not sure if that makes sense on MacOS though.
DYLD_LIBRARY_PATH seems to be pretty much what LD_LIBRARY_PATH is on Linux, according to stackoverflow there's also DYLD_FALLBACK_LIBRARY_PATH: link
I have a small FYI: I'm using v0.8 as a development branch (so the master branch matches the most recently released version) and changed jl-sys to use whitelisting rather than blacklisting. If compilation is slow, I recommend using the whitelisting version because the improvement for Windows and Linux is significant.
I'm working on a roadmap for the next version, it will probably take a few weeks of work before it's ready to be released so don't worry about other changes or branches. If your work is merged before I'm done, I'm planning to release that as v0.8 instead :)
Ah okay sounds good. Sorry for being afk, but some personal work came up. I should be back to help contribute soon.
No worries and no hurry. Compilation was painfully slow on Windows and Linux due to blacklisting, and you might have run into the same issue.
Hello @Taaitaaiger,
I have tried your suggestion (changing the target_os from "linux" to any of ("linux", "macos") in the build.rs of jl-sys), and the basic example worked on my Mac. I am a bit confused by plenty of target_os = "linux" checks in the jlrs itself but I have yet to discover if that is important.
Just letting you know that MacOS support seems to be there with the little change you mentioned. If you want, I can create a PR.
Thanks, that's great to hear! The main reason behind that check is that I haven't been able yet to get the async runtime to work on Windows, if that does work on MacOS it can be changed to support both.
I'll happily accept a PR for this but I think it should also enable CI for MacOS so it can be guaranteed things will work. Would you know how to do that?
Do you mean that in the .appveyor.yml there should be a target for MacOS? I can see there are only Windows targets there now.
That's a good point. I have no experience with Appveyor but I can check how to do it, though it will definitely delay the PR creation.
No, I mean Github Actions: https://github.com/Taaitaaiger/jlrs/blob/master/.github/workflows/main.yml
I originally used Travis for Linux and Appveyor for Windows, but migrated Travis to GA after their free-tier was limited.
I see. There does not seem to be an official OSX Docker image (for obvious reasons). I have found one on Github but, frankly, I am not willing to invest time into trying it out.
Is it really necessary to have CI target for MacOS? You are most likely going to use some Linux distribution when running production code, or use Docker and an Ubuntu/Debian/Alpine/whatever container. I believe, MacOS support is nice during development only, and there is always a Docker fallback (I am actually running both variants at the moment).
That's quite alright, if you make a pull request that will provide support for MacOS I'll be happy to merge it, but I don't think it's right to say jlrs supports MacOS if it isn't tested like Windows or Linux.
I can open a new issue so someone else could contribute that part if they want to.
FWIW,
There is a somewhat working fork of jlrs that supports MacOS here
I have tested it on a mac, and it does require setting DYLD_FALLBACK_LIBRARY_PATH or DYLD_LIBRARY_PATH , which, imo, didn't feel clean enough to upstream.
@Taaitaaiger , would you prefer this or a part of this be upstreamed? I have tested it on MacOS.
(P.S. the documentation did not mention it, but the tests apparently need to run on a single thread, or the test fails)
@Taaitaaiger, you are right, it's not correct to say that jlrs supports MacOS without testing. The made changes only enable using it under MacOS to the unknown extent.
@nikhilmitrax
That would be wonderful! It can be treated as an experimental feature for now until CI is enabled. And yes, It should be documented that running tests requires --test-threads=1 to ensure Julia is only initialized once.