Add additional possible path for Mathematica on MacOS #96
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks for the very nice package!
Issue
Installation on my machine initially failed with the following message during the package build:
For some context, I'm on an M1 Max Macbook Pro and running macOS Sequoia 15.2. I get the following under "About Wolfram" when I look in Mathematica (though "Mathematica" seems to be called "Wolfram for Desktop" now?):
Investigating the paths, it seems that what my machine needed was:
ENV["JULIA_MATHLINK"] = joinpath(path, "Contents/Frameworks/mathlink.framework/mathlink")
ENV["JULIA_MATHKERNEL"] = joinpath(path, "Contents/MacOS/MathKernel")
where
path
was the output ofmdfind "kMDItemCFBundleIdentifier == 'com.wolfram.*'"
(/Applications/Wolfram.app
on my machine). Guessing it has to do with Wolfram renaming some of these things in recent versions?What this PR implements
This PR simply adds this case to the list of cases considered in
deps/build.jl
.I figure that adding to the end of the list has the least chance of breaking cases that are already working, but perhaps the better fix would be to change
MathLink.jl/deps/build.jl
Line 11 in 5f6c5d0
to instead be
Also, I saw that @simonbyrne is implementing what looks to be a better long-term solution in #68. However, that seems to currently be blocked by something on the Wolfram side (if I'm understanding correctly), so perhaps this can be useful to some folks in the meantime?