Make pkgsStatic set "static" argument to true

[KAction]

This change allows derivations to define "static ? false" arguments to
have way to distinguish dynamic musl build and static musl build in
cases where upstream build system can't detect it by itself.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• 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 nixpkgs-review --run "nixpkgs-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)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-distinguish-pkgsmusl-and-pkgsstatic/8745/5

[Ericson2314]

CC @matthewbauer

So far, we've just been overriding individual packages in the overlay. I agree this is rather unsystematic, basically taking on the constraints of a downstream project despite living in the Nixpkgs proper.

That said, we don't add arbitrary configuration to the top-level like this. We would instead probably want to put something in stdenv.*Platform. Take a look at lib/systems/* for how that might be accomplished.

[vcunat]

And... the best practice is (generally) as follows?

• don't build both static and dynamic (in a single build)
• default to dynamic
• use parameter called static to switch (some others have been used)

[KAction]

@Ericson2314 What about this, updated version of patch?

$ nix repl ~/deve/nixpkgs
nix-repl> stdenv.targetPlatform.isStatic
false
nix-repl> pkgsMusl.stdenv.targetPlatform.isStatic
false
nix-repl> pkgsStatic.stdenv.targetPlatform.isStatic
true

This way, to add something specific to static build, change will be only in one place -- in derivation itself, without need to keep list in pkgs/top-level/static.nix. It will help out-of-tree derivations, too.

[vcunat]

And packages would be written like this?

{ stdenv, foo, bar
, static ? stdenv.targetPlatform.isStatic
}:

(So that they can be configured "individually" as well, though I expect most use cases will be fully static builds anyway.)

[KAction]

Not sure about this. If you keep static flag, it means that you can request static build with otherwise dynamic stdenv, which may or may not work (most likely not work, since glibc networking code can't be compiled statically, as I recall), but also it means that you can request dynamic build with static stdenv, which definitely will not work, since that flag was added for a reason.

So actually I expect it to be used like this:

{ stdenv, lib }:
stdenv.mkDerivation {
  name = "foo";
  src = { ... };
  patches = lib.optionals stdenv.targetPlatform.isStatic [./patches/fix-for-static-build.patch];
}

[vcunat]

Well, for me... static isn't all-or-nothing and the flag mainly means whether the output for that package will contain *.so or *.a. In practice, I believe libc is the last part that you want to make static (in the sense that you want it static usually only when you make all other libraries static a swell). Still, I do expect most of "static" use cases will be fully static builds, i.e. those you apparently have in mind.

[KAction]

I do not see reason to not build ".o/.a". Put .so into libs, .a into dev (as it is done in Debian).

[vcunat]

I don't think that works very well in practice. Many build tools assume they both reside in the same directory, it's more difficult for you to choose which is used, etc. EDIT: most notably, pkgconfig allows different options for static and non-static but libdir is common.

[Ericson2314]

Let's start with

{ stdenv, foo, bar
, static ? stdenv.targetPlatform.isStatic
}:

As @vcunat says as it's a nice small step that nevertheless solves the problem.

[KAction]

Am I correct that you want me to remove manual overrides in pkgs/top-level/static.nix and add static ? stdenv.targetPlatform.isStatic to individual derivations into this PR before we can merge it?

[Ericson2314]

No, sorry, I was just commenting on how we might transition away from having the overlay at all. I didn't realize you had ready pushed new stuff to this. Will review in a moment

[Ericson2314]

Just a little bit more work left, thanks.

[Ericson2314]

It is good to set a default here, but let's make it a bit more nuanced, based on

nixpkgs/pkgs/stdenv/cross/default.nix

Line 41 in ab24734

++ (if (with crossSystem; isWasm || isRedox) then [(import ../../top-level/static.nix)] else []);

Suggested change

	isStatic = false;
	isStatic = final.isWasm || final.isRedox;

[Ericson2314]

So we shouldn't be overriding *Platform in overlays, for a number of obscure reasons.

Instead, we should change the definition of pkgsStatic to include isStatic = true; in the crossSystem argument to Nixpkgs.

That, and the pkgs/stdenv/cross/default.nix line I already pointed out above, and are the only places static.nix is used. The fancier defaulting suggestion I made ensures that latter is already in sync with the use of the overlay, so changing pkgsCross like so is the only other fixup needed.

[KAction]

@Ericson2314 Did changes as you requested, works for me as checked in #96223 (comment)