CompilerNode interface

[pretty-wise]

Changes:

• introduce CompilerNode interface that is used by all compiler-running binaries
• create ubercompiler binary
• share AssetRegistry between compilers within the same process

Code dependency graph:

Below illustrates code dependencies of data-compilers and executables that use data-build to trigger those compilers.

            ---------       ---------   ---------
            | a.lib |       | b.lib |   | c.lib |
            ---------       ---------   ---------
                 |             /  \      |
            -------------------- --------------------
            | compiler-a2b.lib | | compiler-b2c.lib |
            -------------------- --------------------
          /                    \/         |
         |                     /\         |
         |  -------------------- --------------------
         |  | compiler-b2c.exe | | ubercompiler.lib |
         |  -------------------- --------------------
         |            |            |        \
--------------------  |            |      --------------------
| compiler-a2b.exe |  |            |      | ubercompiler.exe |
--------------------  |            |      --------------------
          A           |            |
          |           |            |
          |           |            |
          |           |            |
          |           |            |
         ==================    ==================    
         | DATA-BUILD.exe |    | EDITOR-SRV.exe |    
         ==================    ================== 

data_build::DataBuild

data-build.exe and editor-srv.exe are currently the entry points to building data. They do this through DataBuild interface which is responsible for creating the build graph and triggering data compilation in the right order.

• data-build.exe - currently uses each compiler as standalone executable
• editor-srv.exe - currently uses in-process compilers by linking with ubercompiler.lib

data_compiler::compiler_node::CompilerNode

This is an interface used by each binary that does data compilation (such as compiler-a2b.exe, ubercompiler.exe, data-build.exe, editor-srv.exe). This will help us treat each binary as a node in a "compilation network" when tackling the distribution of building game data.

[aganea]

Looks good, thanks!

[aganea]

I always wondered about this, can't we just return a true std::num::ParseIntError here?

[pretty-wise]

From what I remember it is not possible to create ParseIntError (see rust-lang/rfcs#1143).

I was actually thinking we can just use () as the Err type since it's not that relevant/useful I think. But that would need a separate PR.

[aganea]

I had to debug this kind of data-build/compiler tests in the past few weeks, and I was wondering if we could have the corresponding compiler embedded (eventually) in the test executable? Plus, the other issue is that there's no explicit link to the compiler .exe itself, which means that this test & the compiler .exe can be out of date.

[pretty-wise]

Yeah I feel your pain. I either run cargo build before running any tests. Or simply run make test.

As for embedding compiler - this test is specifically testing calling an external executable - which is a path that we still support.

The issue is that cargo does not provide binary dependencies. There is an rust-lang/rfcs#3028 to add it which would help us solve this problem.

All this indeed creates problems. Basically you need to at least run cargo build -p compiler-* for some tests to make sense. This is what we have the build machines configured to do; and make test does the same thing.