-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get dwarf-fortress runnable: just install and type dwarf-fortress
#21288
Conversation
1. Replaced `suite` stanza with `binary`, DF doesn't belong in ~/Applications. 2. The DF binary requires launching from the directory it is in, so we build a shimscript in preflight. 3. The binary's name is `df`, but this conflicts with the OSX `df` command, so the symlink is `df_osx` instead. 4. Part of the installation on modern OSX requires replacing 2 of the framework libraries that are included in the DF tarball. This is now done automatically in postflight with a series of `system` calls.
Downloading extra stuff via |
Darn, I figured extra curling was a big no, but figured I'd send the PR anyway. DF is ancient (14 years old) and only developed by a team of two, so the release format is...particular. Is there some accepted method in Edit: to answer the "why is this better" part, the previous |
System calls are written to a shellscript instead, and the user needs to run the script after installation on their own.
Might #20783 be of interest? |
I guess while I'm running around playing with casks involving DF, I can do #20783 as well, see #21290. :-) I still want to get this change to
|
# http://dwarffortresswiki.org/index.php/DF2014:Installation#Mac | ||
Utils.update_sdl 'SDL_ttf', 'projects/SDL_ttf/release/SDL_ttf-2.0.11.dmg', staged_path | ||
Utils.update_sdl 'SDL', 'release/SDL-1.2.15.dmg', staged_path | ||
ohai "Run #{staged_path}/update_sdl to fetch and replace DF's SDL libraries" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be in a caveats block instead of ohai
I still don’t like that you’re downloading and mountig external things (essentially doing what a cask is for) inside this cask. Can’t you push that to another cask and make this depend on the other? Like we did Lightroom 6.3 depend on Lightroom 6.0. |
Yep, I can do that. I was trying to avoid adding more casks, but if there's a precedent for it, I'm happy to follow it. Thanks for the link the Lightroom cask. There will be two new casks I'll need, should each be their own PR, or can I lump them in here? |
You can lump them - they are related and so one PR makes sense |
There's still some File.rename and File.symlink to be done, but that's not nearly as horrific as the previous mess.
Yes, putting use data alongside binaries is bad, but deleting it outright is even worse.
df_osx
dwarf-fortress
@brewingcode Not actively checking this PR but please comment here when changes are done so we can review and merge ASAP, thanks! |
I think the changes are done....? Let me know! |
Casks look mechanically correct @vitorgalvao if you could look through the shim script, that'd be appreciated. |
depends_on cask: 'sdl-framework' | ||
depends_on cask: 'sdl-ttf-framework' | ||
|
||
binary shimscript, target: Hbc.homebrew_prefix.join('bin/dwarf-fortress') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
binary shimscript, target: 'dwarf-fortress'
should be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried that, but then the dwarf-fortress
symlink ends up in /usr/local/bin
, which doesn't work with Homebrews that are installed outside that default location.
Is there a reason homebrew-cask
completely disregards that setting...? It seems like a bug: clearly homebrew-cask
knows about custom prefixes because it already has the Hbc.homebrew_prefix
property, so why doesn't it respect that property when symlinking binaries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but then the
dwarf-fortress
symlink ends up in/usr/local/bin
Not exactly. It ends up in your binarydir
, which by default is /usr/local/bin
, but may not be. That is a feature, not a bug, and makes sense in a world where HBC and HB are decoupled (currently the case).
We’re discussing changing that.
Currently, though, binary shimscript, target: 'dwarf-fortress'
is then the correct option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I saw that binarydir
command line option, and was surprised that it didn't take its default value from Homebrew's prefix.
OK, I'll change the cask, and maybe add a caveat about passing in --binarydir "$(brew --prefix)"
or such during a cask install
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need about adding that caveat
, as this is not wrong behaviour, it is completely expected and documented.
OK, changes pushed. Sorry for the delay, long week. :-) |
Thank you for your continued work on this. |
My pleasure, thanks for pointing me in the right direction, and for merging. |
…omebrew#21288) Also add casks: sdl-framework 1.2.15, sdl-ttf-framework 2.0.11, to support the main cask
brew cask audit --download {{cask_file}}
is error-free.brew cask style --fix {{cask_file}}
left no offenses.