The Future of LLVM Packaging

Hello, I recently joined the LLVM team for Nixpkgs. I am making this post to explain my involvement and plans with the LLVM package as this is a critical package and I think people will find it informative. To start, my involvement with LLVM began with packaging LLVM 17. I needed it at the time because of my involvement with the Zig Programming Language.

Some time later, I went to the first NixCon NA and met some great people. From there, I decided to become more involved with LLVM in Nixpkgs. Over the past month, I have packages LLVM 18 and worked on refactoring the LLVM Nix code. This refactoring involves moving every subpackage of LLVM for each version of LLVM to rely on a single Nix file for a package. This has an estimated code removal of 6k.

My plans for LLVM’s future is to go from a reactive approach with updating to a proactive one. The reactive approach was to update LLVM’s git version to a newer commit, make the necessary fixes to it, and copy that to a new folder with the name of the version. However, this approach isn’t the best when LLVM can induce changes which causes the Nix code to fail. So I have come up with a proactive approach. My goal is to do an LLVM git update every week on Sunday. Any issues with the LLVM git package gets discovered very quickly. If a patch is required then the goal is to upstream that patch into LLVM itself.

With my involvement, I hope LLVM will become a better managed package as it is considered a core package. If anyone has any PR’s which they wish me to look at for LLVM, please don’t hesitate to mention me on Matrix, Discord, or GitHub. However, just be warned that I may have limited time from time to time so communicating with me first is the best way to get things done.

57 Likes

Thanks for your efforts!

2 Likes

You’re welcome, I hope what I’m doing will also lead to a better experience with using pkgsLLVM as well. One of the things I’m also looking to do is enable new features like C++20 support.

1 Like

Clang and LLVM are both really important for Darwin, so as a Darwin maintainer, I really appreciate the work you’re doing on this.

6 Likes

You’re welcome, I have an aarch64 MBP which I use but I mainly am booted in NixOS because macOS is a pain to use imo.

6 Likes

These refactors look great. Thanks for the work!

2 Likes

Yep, I was wanting to get them in before LLVM 19 as I didn’t want things to diverge. Only like one or two packages in LLVM were already commonified so I just decided to do the rest.

2 Likes

Hi @RossComputerGuy,

Thanks a lot for the great work on LLVM.
A question: is this possible to deliver a combo-package that will have have both clang-tools and clang compiler integrated? I am hitting some issues with clang-tidy with the internal compiler headers (like xmmintr.h) and the LLVM github suggests that I should be using clang-tidy installed in the same location as clang itself. Currently I don’t think we have a package like that in nix. Any thoughts?
Here is the GH comment for reference: [clang-tidy] Fix handling --driver-mode= by PiotrZSL · Pull Request #66553 · llvm/llvm-project · GitHub

The reason as to why clang-tools is in its own package is because those tools come from a different part of the LLVM source code. You might be able to make a new package using symlinkJoin and substituteAll. When I have the chance, I could look into this properly and find an upstream fix.

2 Likes

It turned out that the headers problem is solvable even with split packages. I had to add few --extra-args-before with an “-isystem”, “/path/to/clang/headers” and some defines that were missing to get clang-tidy to work.