-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split build.cc #3098
Split build.cc #3098
Conversation
First step towards actually splitting the implementation
Make the build more incremental and the file easier to digest
I'm not really in favor of this since I'd rather 1) rewrite in async Rust or 2) rewrite in C++ using threads or fibers instead of the current per-goal state machine. That's more useful than having a lot of code churn that doesn't change functionality. |
All right, I'll close it then |
Let's give this another shot! @edolstra you said reducing the build critical path latency now makes this worth it to you, right? |
Yes although I did an experiment today about the overhead of the C++ compilation model and it turns out you get a 7x compilation speedup by concatenating all source files into a single compilation unit. In other words, splitting |
I've start resurrecting it. Thanks to @regnat splitting the commits vary well, it's less hard to recreate than I feared! |
@edolstra I prefer to use things like https://mesonbuild.com/Unity-builds.html for that :D. Then downstream builders can choose to either to maximize parallelism or minimize total work without upstream developers having to do extra work to support both. I personally am building Nix with |
Would be great then to use meson and have both incremental and unity builds :) |
Reopened as #4114 |
All the build logic of nix is bundled into one gigantic cc file.
From my experience of discovering the nix codebase, this makes
understanding and navigating the code quite difficult, and also cause
the rebuilds to be awfully long once we touch this file.
This MR splits this file to
Barring any error on my side, this shouldn't have any functional impact
since it only moves functions around and doesn't change any code.
I couldn't test this outside of my own machine, so I'm not sure that I didn't
break the build on other platforms because of the changes in system
imports. Is there an easy way to test this somewhere?