Sorry for my first post being this. I just started with NixOS, and I’m going to stick with it. Presently, I am recompiling the entire operating system to target Haswell architecture on a T440P. This takes quite a bit of time.
This may already have a simple solution. I’m certain it already has a complex solution. I welcome being told about either, but would still like a simple solution to become a built in default, ideally. With enough information I can try to develop it myself. The problem is:
14 hours into a recompile, I had a misnamed package in my system packages, and the process aborted. It seems like you could check that by default before the entire system tries to recompile. Again, I am sure this is a self caused problem, and I am not asking anyone to exert effort on it, but this is the first thing I’ve experienced with Nix that genuinely upset me, so if nothing else this is a vent post.
nix expressions are handled in two phases, evaluation and building. Evaluation errors (like typos) would be caught before building can begin - since in a declarative lang, the entire chunk of code needs to be valid before it can do anything, and nix needs to know what to build in the first place.
If it failed during build, then whatever successfully built until that point is cached - so it’s not wasted time either.
If the machine was really spending 14+ hours on eval, that sounds excruciating to build on - but I don’t think the thinkpad hardware is that low-end? If you can post the error, it’d be easy to ID if it’s a build or eval error.
I don’t think taking 14 hours to do that is unexpected, @Alephwyr is presumably doing the thing where you override the -march and gcc tuning flags for everything and then just wait it out.
FWIW, this is not really a feasible way to use NixOS. Unlike gentoo, NixOS doesn’t aim for low compilation time, and since nix rebuilds packages whose dependencies have changed (recursively) you’ll be building the full tree very regularly (about once a week AIUI, upstream does try to avoid rebuilding the world).
You’re probably better off overriding the optimizations for a specific subset of packages where you think you need them. You’ll probably want to avoid doing so with the kernel or your browser, though.
That’s correct, that is what I’m doing. I didn’t realize this would be an every time thing, that is obviously not workable. I will take your advice. Does specific package overriding depend on the use of flakes? I guess everything is driving me towards learning them at this point.
Flakes are completely unrelated - just think of them as a way to download nixpkgs, in the context of a basic NixOS config.
If you can give a specific example you want to recompile we can help further - just note that optimizations are often placebo, so benchmark afterwards to see if it was worthwhile.
For the record, we should explain why this only failed 14 hours into the build. Nix does evaluate your config before building it. So the misnamed package in systemPackages should be caught at eval time, before any building occurs. But the nixos-rebuild tool does a funky little trick, where it builds the new version of nixos-rebuild before it evaluates / builds the full config, and reexecs the new nixos-rebuild to eval / build the full config. So those 14 hours were probably spent building the new nixos-rebuild, and then the failure happened at eval time when that was used to evaluate the full config. This can be avoided with --no-reexec.
The reexec-by-default is intentional to ensure that current bugs in nixos-rebuild generally won’t prevent you from future rebuilds - so don’t use this flag unless you’re deploying remotely or something.
It is unfortunate though that it eval’d only config.system.build.nixos-rebuild without checking config.system.build.toplevel - IMO that could be fixed.
Well, part of the point of the reexec is also to use the new version of Nix when evaluating toplevel. So you don’t wanttoplevel to be evaluated before it builds and reexecs nixos-rebuild.
Seems doubtful. Either way --no-reexec is not a solution, because you’ll have to build nixos-rebuild at some point whether now or later, if it’s part of your config. There’s still no good reason to use --no-reexec unless there’s a bug in the reexec code.