MolecularMatters/lpp_public

Feature request: make unity splitting smarter about large unity files

Opened this issue · 1 comments

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++ ?

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.