Here be dragons.

1. Make a zip backup of the runtimes. In fact, do it with a zip file for each runtime, and you're ready to merge. Oh, and keep a copy of the zipped runtimes. That way you always have them. Start the zip at the runtime, itself. Not the parent. Name them something meaningful.

2. do 1. Really make sure you do it. Keep the zips somewhere safe. You can use those to always get back anything. I've gone back to old zipped runtimes years later.

3. In a new directory, unzip the runtimes over top of each other. Put the first in the new directory, then unzip each over it. unzip, by default, just adds new files, overwrites a file of it's already there. There are options to control what happens, if you don't want overwrite or if you want it to warn, at least.

That's it. You've just combined all the runtimes into a single one. If no file clobbering happened, then you're done.

potential problems you can have:

• different runtimes have the same filename in same path but they're really different files. This will ruin anything that uses the clobbered file. I've had this problem. Usually this is for older and freebie stuff. Vendors tend to be more careful.

• it also matters if your filesystem is truly case insensitive or not. By default, macOS is not. It appears to be, but it's not. Same potential clobbering problem. /file will be overwritten by /File. This just increases the "clobber space". Say one person named their file geometries/shoe.obj in one runtime but another runtime named theirs geometries/Shoe.obj. The filesystem would treat them the same when merging.

If you really want to be careful (and this is not easy to do): before you merge the runtimes:

You could detect the duplicate paths but different files with a command that checks two (or more) directory trees and looks for paths that are the same. Once you have that, you need to verify the files are actually different. The tools for doing this (on *nix) are find, grep, jdupes And the command line switches are not trivial. But they do it, and very fast.

de-duping: if you use something like a *nix FS: optional properly de-dupe to hardlinks. You can gain a lot of space this way. Done properly, it dedupes the files, regardless of what they're named, then sets hardlinks with the original filenames. For instance, let's say a vendor has /runtime/textures/vendor/product/hair-TR.jpg and /runtime/textures/vendor/other-product/coolhair-TR.jpg and they're both really the same file, just copied. de-doping will find it, and have just the one file. The second filename is just another name for the same file. Keep in mind that filenames are actually convenience "links" to the actual disk space. hardlinks are just another link to the same disk space. Your OS just gets the same space using a different path. The FS tracks how many names reference the same location. When you delete a HL, it just removes the name from the list. When you remove the last name, it also marks the space as "free" (ie: deletes the actual disk space, since there's no more names that reference it).