Skip to content
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

dwarf-fortress: TWBT & Lazy Pack #43081

Merged
merged 2 commits into from Jul 9, 2018
Merged

dwarf-fortress: TWBT & Lazy Pack #43081

merged 2 commits into from Jul 9, 2018

Conversation

Baughn
Copy link
Contributor

@Baughn Baughn commented Jul 5, 2018

Motivation for this change

The DF directory menaces with spikes of Nix code. It's difficult for a new user to know how to use it.

This adds dwarf-fortress-full, an admittedly opinionated configuration that should suffice as a starting point, and may suffice in general.

It also adds the TWBT plugin to dfhack, which makes text look nicer in general.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

@Baughn Baughn changed the title Nix df dwarf-fortress: TWBT & Lazy Pack Jul 5, 2018
++ lib.optional enableDwarfTherapist [ dwarf-therapist ]
++ lib.optional enableLegendsBrowser [ legends-browser ];

meta = with stdenvNoCC.lib; {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just do with lib here.

@@ -0,0 +1,35 @@
{ stdenvNoCC, fetchurl, unzip }:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of a nitpick but I prefer to just use stdenv & put stdenv = stdenvNoCC;.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether or not it needs the compiler is a property of the TWBT package, no? Not its caller. There is no use in overriding that parameter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes that's make sense. Would it be difficult to make it build from source? They provide a CMakeFiles.txt that looks pretty simple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They haven't tagged their releases, so I wouldn't know which git reference to use. I don't think we'd gain anything from compiling from source, either?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would make it more portable. For instance "twbt.plug.so" is compiled for x86_64-linux. Someone might want to compile a version for i686-linux as well - or something besides linux. We also frequently hit issues where the linked libc.so or libgcc.so are not the same version on the system so it hits an issue (especially on NixOS where things are not always in the right place).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, but we still don't have release tags. I'll raise the issue with the author; in the meantime, I'll edit this commit to include 32-bit linux as an option. Kind of forgot that people still use that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok yeah I would say for now it's okay - just definitely possible to improve it later on.

# This package should, at any given time, provide an opinionated "optimal"
# DF experience. It's the equivalent of the Lazy Newbie Pack, that is, and
# should contain every utility available.
, enableDFHack ? true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be wrong but I think if you set this to stdenv.isLinux this will support macOS out of the box. I'll need to test to verify though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think a few of the wrappers might still be broken.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might have an older version. I noticed I'd used lib.optional wrongly, which broke the legends-browser and dwarf-therapist packages.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's still a few places we assume linux actually but I think we're closer:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/games/dwarf-fortress/dwarf-therapist/wrapper.nix#L6

But I think it's closer. I tried to get dfhack working on macOS but it was more difficult than I thought.

@matthewbauer
Copy link
Member

This would be very useful! If it works well I think it would be useful to just set dwarf-fortress = dwarf-fortress-packages.dwarf-fortress-full; in all-packages.nix.

@Baughn
Copy link
Contributor Author

Baughn commented Jul 5, 2018

I've updated TWBT to the new version of DF, and it at least builds now, but I'm getting warnings because it's not intended for this version of DFHack. It's the newest version available, though.

@matthewbauer
Copy link
Member

Ok after #43085 you should be able to do (dwarf-fortress-original.override ({ dfVersion = "0.44.10"; }))

@@ -33,40 +34,47 @@ let
fi
'';

in stdenv.mkDerivation rec {
name = "dfhack-${version}";
dfhack = stdenv.mkDerivation rec {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay this might be better to leave dfhack as is & create a "wrapper.nix" file to contain the buildEnv stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're the guy with commit access, but IMO these two derivations are logically grouped, so it should be fine to keep them in the same file. Changes to one may well require changes to the other.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok probably okay for now just. Is the PR okay to merge or are there still issues?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be fine to merge, but won't work well until I can rework it based on the other one. I'll leave that decision up to you.

@matthewbauer matthewbauer merged commit b0c7245 into NixOS:master Jul 9, 2018
matthewbauer added a commit that referenced this pull request Jul 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants