You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love the idea of unity splitting, but it does not work that well on our project, in which a unity file can reference up to 250 compilands - which means that patching or deoptimizing leads to rebuilding 250 files... Per affected unity. The obvious workaround is to disable unity splitting.
It would help if Live++ tried to do the same thing as FASTbuild does when encountering editable files: removing them from the unity they belong to. Would that be an option for Live++ ?
The text was updated successfully, but these errors were encountered:
linkablonk
changed the title
Feature request: make unity splitting smarter
Feature request: make unity splitting smarter about large unity files
Apr 5, 2023
Yes, that is a good suggestion - we've had that on our internal "Future Ideas" list for some time now.
We would like to keep what we have right now as the "Default mode" for unity splitting and introduce a new "Adaptive mode" that does what you say, splitting off single files from larger unity files.
Since Live++ does not create these unity files and never touches source files, it is a bit harder to do. But still possible.
I love the idea of unity splitting, but it does not work that well on our project, in which a unity file can reference up to 250 compilands - which means that patching or deoptimizing leads to rebuilding 250 files... Per affected unity. The obvious workaround is to disable unity splitting.
It would help if Live++ tried to do the same thing as FASTbuild does when encountering editable files: removing them from the unity they belong to. Would that be an option for Live++ ?
The text was updated successfully, but these errors were encountered: