Skip to content
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

Closed
wants to merge 4 commits into from
Closed

Split build.cc #3098

wants to merge 4 commits into from

Conversation

thufschmitt
Copy link
Member

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

  • Make the code easier to navigate
  • Make builds faster (more parallelism and incrementality)

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?

First step towards actually splitting the implementation
Make the build more incremental and the file easier to digest
@edolstra
Copy link
Member

edolstra commented Sep 20, 2019

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.

@thufschmitt
Copy link
Member Author

All right, I'll close it then

@thufschmitt thufschmitt closed this Oct 3, 2019
@Ericson2314
Copy link
Member

Ericson2314 commented Oct 6, 2020

Let's give this another shot! @edolstra you said reducing the build critical path latency now makes this worth it to you, right?

@edolstra
Copy link
Member

edolstra commented Oct 6, 2020

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 build.cc will make non-incremental builds slower unless you have a lot of cores...

@Ericson2314
Copy link
Member

I've start resurrecting it. Thanks to @regnat splitting the commits vary well, it's less hard to recreate than I feared!

@Ericson2314
Copy link
Member

@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 -j50 so you know which I prefer :).

@domenkozar
Copy link
Member

Would be great then to use meson and have both incremental and unity builds :)

@Ericson2314
Copy link
Member

Reopened as #4114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants