Replace all `enableStatic` arguments in Nixpkgs, with `stdenv.hostPlatform.isStatic` and instruct people to use `pkgsStatic`?

Development
1

In PR 311411 I ran into a confusing behavior of a package, related to it’s enableStatic and stdenv.hostPlatform.isStatic.

I’m claiming that any appearance in Nixpkgs of enableStatic should be replaced with stdenv.hostPlatform.isStatic, and having 2 ways to do the same thing is confusing, and pkgsStatic is much more versatile in comparison to using .override { enableStatic = true;} for every package.

Would like to get some input on this argument.

1 Like
2

I have seen people report usecases which benefit from enableStatic over the use of pkgsStatic, but I don’t have any such use case personally

3

Thanks for responding :] Do you have an example? I can imagine a package which has such an enableStatic argument, which makes the derivation be evaluated differently in comparison to pkgsStatic. What I’m suggesting, is to switch all usages of this enableStatic, with stdenv.hostPlatform.isStatic.

Maybe the word “remove” in the title of this thread is inaccurate, so I updated the post.

4

How about defaulting enableStatic to stdenv.hostPlatform.isStatic? Then both work: you don’t have to build the pkgsStatic world to build a enableStatic static package, yet pkgsStatic just works

4 Likes
5

Say package A which produces by default liba.so, depends and links against package B which has libb.so. If you want package A be completely static, and you try to build it with packge B’s libb.so in it’s buildInputs, how could A ever be functional this way? Or what is the expected behavior in this case?

I claim that if you use A.override {enableStatic = true;} in such a case, you’d have to propagate the enableStatic argument to the B package used in A’s buildInputs, and that sounds like something that pkgsStatic does much better, automatically.

6

@NorfairKing any comments? I think you were building static icu outside pkgsStatic, right?

7

These don’t do the same thing.

  • pkgsStatic uses a different libc: musl instead of glibc.

  • enableStatic adds --enable-static to configureFlags, which (in most cases) builds a .a library which still links against glibc rather than musl. The stdenv bootstrap uses and relies on this behavior.

Yes it’s confusing, but neither of these replaces the other. A better strategy is to try to build statically-linked binaries by default, in addition to dynamically-linked binaries, and only provide the enableStatic option when the build machinery makes it impossible to do that.

In the specific case of GH311411 I think you should just rename the option, because there enableStatic doesn’t do what it does everywhere else. You should pick a name like enableFhsTerminfoDirs or something.

3 Likes
8

1d
How about defaulting enableStatic to stdenv.hostPlatform.isStatic? Then both work: you don’t have to build the pkgsStatic world to build a enableStatic static package, yet pkgsStatic just works

Yes this is what the PR (which has been approved already, just not merged yet) does.

I think you were building static icu outside pkgsStatic, right?

That’s right. I’m statically linking against musl via pkgsMusl outside of pkgsStatic because I don’t need all dependencies to be statically linked, only linked against musl.

In the specific case of GH311411 I think you should just rename the option, because there enableStatic doesn’t do what it does everywhere else. You should pick a name like enableFhsTerminfoDirs or something.

That’s a fine improvement, but let’s make improvements after we merge the already-approved fix, and in a different PR.