So I’m writing a nix expression for facebook’s static analysis tool infer v0.15.0. This version of infer depends on this version of facebook’s custom clang.
The project structure is such that the facebook-clang-plugins repo is a git submodule in the infer repository. The top-level Makefile for infer calls the Makefile for facebook-clang-plugins (which, among other things, calls cmake and make for their custom clang).
|infer/
|--Makefile
|--build-infer.sh
|--facebook-clang-plugins/ @ f31f7c
|----Makefile
|----clang/
|------setup.sh
|------src/
|--------clang.7.0.0.tar.xz # note that llvm uses cmake to build
|------install/ # this is the default install location for custom clang
However, the build process for both infer and clang is quite time-consuming, and because of the script organization I’m not even entirely sure that the Makefile at the top level would work for everything inside nix. So, I’ve been writing two separate packages for facebook-clang-plugins and for infer.
Is there a better way to organize these two things? The facebook-clang project will probably only ever be used for building nix; is there a preferred structure inside nixpkgs for packages that look like this?
I currently have:
|facebook-clang-plugins/
|--default.nix
|--opam.lock # because the custom clang requires some opam support
|infer/
|--default.nix
|--opam.lock # same lockfile as above
I have been playing around with something like this:
|infer/
|--default.nix
|--opam.lock
|--facebook-clang/
|----default.nix
where infer’s default.nix has this line to use fb clang as a dependency:
facebook-clang-plugins = pkgs.callPackage ./facebook-clang {inherit pkgs;};
However, testing the second approach with some simple packages seemed to result in rebuilding all dependencies whenever I ran nix-build, which is part of the problem I’m trying to avoid. The custom clang is a separate package from infer and doesn’t necessarily need to be recompiled when infer has a version bump.
Is there something I’m doing wrong with the second approach? Is there a good way to organize a package that has very unique dependencies that won’t be used by other packages, or should I just add both of these separate packages to nixpkgs?
Sorry for the convuluted question. If there’s no clear-cut advice I’d appreciate being pointed towards other nixpkgs that might have similar problems so I can learn how it’s been dealt with in the past.