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

Unity Builds #3226

Closed
nordlow opened this issue Jun 20, 2017 · 4 comments
Closed

Unity Builds #3226

nordlow opened this issue Jun 20, 2017 · 4 comments
Assignees
Labels
P4 type: feature request

Comments

@nordlow
Copy link

@nordlow nordlow commented Jun 20, 2017

Are there any plans to add unity-builds-support for library and program targets?

For instance, Meson has builtin support for unity builds.

It would be really neat if the build system could automatically detect which source-files are so small in size (and in turn in compilation time) that they should be grouped together and compiled into a single object before being linked to a library or program.

@MarkusTeufelberger
Copy link
Contributor

@MarkusTeufelberger MarkusTeufelberger commented Jun 20, 2017

Seems to hurt parallelism and artifact caching... maybe it could be enough to prefetch files that will be compiled? After all, Bazel should already know which files it will access during a build, so there might be a way to notify the OS about this fact.

This would still take a hit from spawning a full sandbox + compiler process etc. for each (tiny) file, but could already be a way to do what unity builds are doing.

I personally am not a big fan of unity builds, since they lead to large files only consisting of "#include" statements and can hide missing includes in the actual files (since the missing header is then included in the unity file). They seem to me like a hack to get around some problems in code layout, disk caching or compiler startup time, not so much like a good design pattern.

When developing, they seem to hurt your re-compile time and fill your cache with larger files - and when building a release you are probably not that concerned about build time anyways.

That all is just my personal opinion though, unity builds are not a feature I would use or recommend to be used, but they might have their merits for some people or projects.

@philwo philwo added P4 type: feature request labels Jun 21, 2017
@philwo
Copy link
Member

@philwo philwo commented Jun 21, 2017

I don't think is on our roadmap and maybe not even a wanted feature for Bazel, but assigning to @lberki to have a look.

@lberki
Copy link
Contributor

@lberki lberki commented Jun 21, 2017

@mhlopko

I'd empathically advise against doing this, mainly because I have experience with it.

My experience is that if this is done, individual source files will inevitably influence each other through included files and #defines leaking from one to the other. A much more principled approach is modules. Then you avoid parsing and compiling a lot of header files and thus gain performance without compromises like the above.

If you really want to do this, you can always do it manually, but doing it automatically based on heuristics is asking for trouble.

@lberki lberki closed this Jun 21, 2017
@Bu11etmagnet
Copy link

@Bu11etmagnet Bu11etmagnet commented Nov 25, 2020

Nobody same uses unity builds during development (because those who do would have been driven insane by the build times caused by compiling every single source file), which means that includes leaking from one source to another is a strawman argument. The alleged bad practices enabled by unity build would break the daily dev builds.

Unfortunately, modules is not the solution, as long as the standard library is not fully modularized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 type: feature request
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants