How should library package variants be exposed?

Development
1

I’m tasked to offer a highctidh to Nixpkgs. It seems the C library comes in four variants:

  • libhighctidh_511.so
  • libhighctidh_512.so
  • libhighctidh_1024.so
  • libhighctidh_2048.so

In addition to that, it supports being built by either gcc or clang, doubling the variants.

What’s the idiom in Nixpkgs for how such variants should be exposed, please? Links to existing examples should suffice.

2

I think we usually ship all variants when it’s like the 4 you listed. However, support for being built by Clang or GCC shouldn’t be exposed unless someone changes the stdenv via an override to clangStdenv or using pkgsLLVM.

3

And this part:

an override to clangStdenv or using pkgsLLVM

“just works”, right? The stdenv input will be overridden and if I care about the success of that, I’d just have to manually test it?

And what if I want Nixpkgs CI to test the clang-built variant of it, please?

4

It should

Yeah, as long as stdenv is in the function inputs for callPackage, the override should work. pkgsLLVM is a good way to test but you’ll have to build all dependencies but you won’t have to override anything.

You could call ofborg to do so in a PR. But currently, it isn’t supported with Hydra. It’s been an idea I’ve been having for pkgsLLVM but many things are needed still.

1 Like
5

darwin stdenvs default to clang, so that way you can get basic coverage of both.

2 Likes
6

That is a good point, I forgot about it. However, not every package might support Darwin’s API’s but Darwin might cover a good chunk of packages in nixpkgs. There’s also stdenv differences between pkgsLLVM on Linux and the Darwin stdenv.

1 Like
7

At a quick glance I had seen a C library implementing a crypto algorithm. That seems like the type of stuff that should be well portable, but I haven’t looked deeper.

1 Like
8

Yeah, I was just mentioning it for future reference in case someone comes back here with a similar problem.

1 Like