Enabling this by default will introduce a whole bunch of python dependencies into the darwin stdenv, we had a similar problem with llvm/clang.

disabling it upstream implies that enabling it locally will trigger may local builds.
What makes darwin special ? it will also pull the python env for linux.
Would disabling it for darwin be a satisfactory solution ?

For stuff like this, we could add some sort of stdenv.isBootstrapping flag that is set for all the bootstrap phases but not in the final stdenv (assuming packages don't get propagated through it) and then have withDoc ? !stdenv.isBootstrapping. That would conceivably allow us to build more minimal versions of packages during the bootstrap, and skip stuff like this, while still giving end users the bells and whistles they want.

I disabled the manpages by default for clang, but added clang.man and lowPrio clang-manpages pointing to a variant with the manpages enabled to avoid rebuilds.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/llvm/4/default.nix#L34-L38

Doesn't overrideManOutput always includes manpages ?

llvm = overrideManOutput llvm;
with
  # Add man output without introducing extra dependencies.
  overrideManOutput = drv:
    let drv-manpages = drv.override { enableManpages = true; }; in
    drv // { man = drv-manpages.man; /*outputs = drv.outputs ++ ["man"];*/ };

didn't know about lowPrio that's interesting

stdenv.isBootstrapping: similar situation doesn't only happen during stdenv bootstrapping. There are other cases where we have "lighter" versions to reduce the build-time closure or even break cycles (sometimes also run-time closure, but multiple outputs can often handle that one).

Yeah, there are a number of cases where we want to reduce build dependencies compared to interactive use. Even tho clang/cmake are not part of the stdenv on linux those still cause a verly large amount of rebuilds.

Anything feel free to take over, I don't intend to continue working on this (due to time constraints).