"Proxies" are a special type of recipe that were added to help resolve issues early on when building std.toolchain. The problem was that some recipes would be used many times during the build-- say, Bash (especially the stage 2 build). This meant that the Bash recipe would be duplicated wholesale every time was used. Bash itself goes through a pretty complex build pipeline-- including gcc stage 2, Bash stage 1, gcc stage 1, and others. The JS side would construct an identical object for each usage, and the Rust side would have to deserialize each instance individually-- leading to a lot of extra time and memory being used during the build.
A proxy is just a recipe that references another recipe by hash. When built, we look up the original recipe by hash and evaluate it instead. The JS side can create a proxy at any time using the op_brioche_create_proxy op, which returns the hash for the proxy. Then, that hash is used cheaply to reference the original recipe, rather than having to build a new object every time.
This approach works and was a key part of the initial MVP for Brioche! But it's still a bit of a kludge, and an obscure tool. Consider the following:
So basically, I'm hoping we can completely circumvent the need for proxies, most likely via #328. If we do this, we would no longer have a need to use proxy recipes, which in turn could simplify brioche-packages as well as future features in Brioche.
"Proxies" are a special type of recipe that were added to help resolve issues early on when building
std.toolchain. The problem was that some recipes would be used many times during the build-- say, Bash (especially the stage 2 build). This meant that the Bash recipe would be duplicated wholesale every time was used. Bash itself goes through a pretty complex build pipeline-- including gcc stage 2, Bash stage 1, gcc stage 1, and others. The JS side would construct an identical object for each usage, and the Rust side would have to deserialize each instance individually-- leading to a lot of extra time and memory being used during the build.A proxy is just a recipe that references another recipe by hash. When built, we look up the original recipe by hash and evaluate it instead. The JS side can create a proxy at any time using the
op_brioche_create_proxyop, which returns the hash for the proxy. Then, that hash is used cheaply to reference the original recipe, rather than having to build a new object every time.This approach works and was a key part of the initial MVP for Brioche! But it's still a bit of a kludge, and an obscure tool. Consider the following:
brioche-packagesSo basically, I'm hoping we can completely circumvent the need for proxies, most likely via #328. If we do this, we would no longer have a need to use proxy recipes, which in turn could simplify
brioche-packagesas well as future features in Brioche.