@matthewbauer suggested

I'm not sure if I exactly like "isStatic". Probably a better name is isStaticLibraries and isStaticBinaries for each of the stdenv adapters.

Any comment on that?

+1 on having a standard way of querying whether a package should build static/shared libaries and static/dynamic executables, but:

@matthewbauer suggested

I'm not sure if I exactly like "isStatic". Probably a better name is isStaticLibraries and isStaticBinaries for each of the stdenv adapters.

I heavily agree with this.

I think isStatic is not enough, and not a good name. For my use case (building static Haskell executables), I (and some others, see #61575) need packages to build:

• static libraries (.a files)
• dynamic libraries as well (.so files) so that TemplateHaskell can load them
• I do not need them to build static executables (e.g. I don't need a statically linked curl exe; that just makes it more complicated)

Others want only .a (.so being absent), and again others want static executables.

These multiple choices cannot be expressed with a single isStatic bool.

Consequently, I think that the

, enableShared ? !stdenv.hostPlatform.isStatic

proposed in this PR, is not good, and that we should rather have names like buildStaticLibs, buildSharedLibs (which can be used in any combination, except perhaps false/false because then we would not build anything), and buildStaticExes.

@nh2

I do not need them to build static executables (e.g. I don't need a statically linked curl exe; that just makes it more complicated)

remember the hostPlatform part. For pkgsCross, stdenv.buildPlatform.isStatic = false while stdenv.hostPlatform.isStatic = true. A build-time curl won't be statically linked.

But stepping back a bit, stdenv.buildPlatform.isStatic already exists, and the overlay has all the same issues you describe as this PR. I would think actually think this is is closer to what you want, because it's much easier to make more parameters than make more overlays.

So there's definitely a benefit to putting everything in one place - most maintainers don't know about static overlay so having lots of isStatic conditionals in their definitions will make them aware they need to test this. It also means we expect pkgsStatic to really be supported everywhere and it's more than just an after thought. I think we'll need to make sure Nixpkgs maintainers for these packages are okay with that extra burden.

@Ericson2314 Would you consider moving "isStatic" to "stdenv" instead of "stdenv.hostPlatform"? Conceptually, I think this is an important distinction because:

• "stdenv.hostPlatform" describes what ABI and toolchain we are using. You can never link packages from two different hostPlatform's together. But "static" / "shared" is much more flexible. You can always have some packages that are static and others that aren't but they link together fine. This hasn't been explored much, but I think it's important to leave this open especially with things that need shared linking like GHC / Template Haskell.
• "stdenv" is where the stdenv adapter is applied, so it's a natural point to determine what our stdenv.mkDerivation is going to do. This would more clearly separate the stdenv toolchain from the crossSystem description.
• "crossSystem" should be limited to what's needed to make a cross toolchain (arch, vendor, kernel, environment, linker, compilers, etc.). That's the part of the stdenv that's special for cross-compiling. All other static logic can be shared with native compilation.

@matthewbauer I don't think I really believe in a "platform vs rest" of config distinction.

You can never link packages from two different hostPlatform's together.

But you can:

• Arm hard float with soft-float ABI exists to be compatible
• i486 -> i586 -> i686, etc.
• RISC-V's extension modes
• WASM presumably has feature flags for various draft things
• Fat binaries / bootloaders / runtime cpuid() type thing

True, nothing in this world has discrete interfaces. There is always a comparability relation.

should be limited to what's needed to make a cross toolchain (arch, vendor, kernel, environment, linker, compilers, etc.).

I don't think there is a firm line where "toolchain" ends. And isStatic could very well influence the toolchain itself by deciding whether to build a dynamic linker.

"stdenv" is where the stdenv adapter is applied, so it's a natural point to determine what our stdenv.mkDerivation is going to do. This would more clearly separate the stdenv toolchain from the crossSystem description.

Well, I also am not sure we we want to stick with a stdenv adapter long-term either. We could use isStatic with the default autoconf / cmake / meson flags just like we do with the rest of *Platform

Finally, it's totally reasonable one would look at stdenv.buildPlatform.isStatic or stdenv.targetPlatform.isStatic, and that's a bit more cumbersome with stdenv.isStatic, especially because targetPackages.stdenv.isStatic is more likely to hit infinite recursion.

OK if no one says anything son, I think i want to merge it because this rots decently.

• I did @matthewbauer's change for GCC, though I have some misgivings.
• The isStatic changes are technically orthogonal, so we can always do them after.

Could you rebase on master instead of having a merge.