bochs: configure it via module system

[AndersonTorres]

Description of changes

Playing a little bit with the module system proposed by @Atemu at #312432.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Atemu]

Lists compose quite poorly. A better design could be to make these a bunch of individual options or a freeform attrset such that you can set them like this:

{
  sdl2 = true;
  term = true;
  wx = true;
  x11 = true;
  somethinElse = false;
}

[AndersonTorres]

a bunch of individual options

Like the previous commit?
0e3afc4

a freeform attrset

Like this?

options = {
  interfaces = lib.mkOption {
    default = {
      sdl =  true;
      term =  true;
      # . . .
    };
  };
};

[Atemu]

Like the previous commit?
0e3afc4

Yes, like that.

Like this?

options = {
  interfaces = lib.mkOption {
    default = {
      sdl =  true;
      term =  true;
      # . . .
    };
  };
};

Not quite. This issues because setting the option overrides the entire default attrset, leaving only the overridden values.

What I meant is an RFC42 settings-like option.

This lends itself to scenarios where there are a bunch of settings where it's unreasonable effort to have individual options for each or where you only want to specify a subset of all settings the program can understand.

For packages, I think that's a rather rare requirement though and I don't think it's necessary here.

[AndersonTorres]

I like to use Bochs expression as a "test+documentation" example.
I wanna try that settings-like approach just for the docs.

[Atemu]

When you have individual options, you could also experiment with having the buildInputs deps declared with each option like I did with ffmpeg.