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.

[Atemu]

Re: availableOn

You can take this one step further if you have the deps declared with the option and automatically apply it to all packages and decide the default on that.

I had considered doing something like this for ffmpeg too but IIRC it was too costly in eval time for questionable benefit.

I had even gone one step further and tryEval'd the toString of the drv in order to catch any sort of eval failure, including transitive ones.

[Atemu]

Atemu@9a0d986

[AndersonTorres]

I am thinking on how to "extend" this correctly.

Usually, SDL packages need to be put in both buildInputs and nativeBuildInputs, especially with strictDeps set as true.

This way, a config.sdl = true; should come with something filling both *lists at the same time.

However

• I don't know if splicing will break (no one does)
• I am unable to remember if buildInputs receive either pkgs.sdl or buildPackages.sdl...

[Atemu]

SDL packages need to be put in both buildInputs and nativeBuildInputs, especially with strictDeps set as true.

Would be interesting to know why that is; which executable of SDL gets executed here.

This edge-case can be handled by bespoke logic though while everything else still gets handled generically.

I don't know if splicing will break (no one does)

I don't see how this would break splicing? The pkgs in packages are still spliced; nothing un-spliced them.

I am unable to remember if buildInputs receive either pkgs.sdl or buildPackages.sdl...

buildInputs are depsHostTarget but we don't call them that for historical reasons.

buildPackages are pkgsBuildHost but we don't call them that for ??? reasons.

Therefore, buildPackages don't go into buildInputs. (pkgs == pkgsHostTarget)

[AndersonTorres]

Would be interesting to know why that is; which executable of SDL gets executed here.

My guess:

SDL has a sdl-config, its own pkg-config-like utility. This utility goes into its own bin output.
Because of this, packages linking to SDL usually needs SDL in buildInputs (libraries) and nativeBuildInputs too (the config utility).
Otherwise, errors like sdl-config not found happen.

On the other hand, Bochs uses pkg-config directly, so no problem here.