refactor: move all motoko specific info to motoko info

[hansl]

And add build steps and move other stuff around.

[hansl]

This is Yak Shaving work for the Rust compiler support in dfx.

[ghost]

Is there any need for this to indicate that it is the wasm output path that wasn't found, similar to the IDL file in the previous file?

[hansl]

Done.

[ghost]

Wondering about these two methods.

• could they be in a separate CanisterOutputInfo trait?
• do all canisters have WASM and IDL output? If so, do the fields with those paths belong in the CanisterInfo struct?
• or will these two methods become a long chain of if..else if statements, one for each Motoko, Rust, Assets, and so forth?

Also I think it's ok to leave these as-is and let this shake out as we add more builder types.

[hansl]

I was pondering this late last night and decided to move those decisions to later, but you're right.

The "only" output we care about from a compile step is WASM + IDL. The rest can be generated by the build step outside the compiler. This is kind of already the case in parts of the code; BuildOutput is the type returned by a build step and contains only those 2 informations. But that structure is not available outside of actually building. So install doesn't have access to it. Which makes it a bit awkward (since we don't want to build everytime we install).

There is a number of solutions and constraints here that require some design work;

• One constraint is the Motoko compiler takes a directory for all IDL files of dependencies (with a specific pattern) so it knows when you're importing a ic:abc what API it has.
• These should be specific info setup by the MotokoBuilder anyway, as it's only needed for Motoko (other builders might have different solutions).
• We would need a temporary directory for compilation (not a big deal) AND an output directory that follows a standard.
• One solution is to have a manifest file which contains all the data we need once the build is done. I like this solution because it also can contain info like buildtime and SHA of inputs, if we ever want to make a watch mode at some point. But this is a potential solution that I haven't explored.

This is a hacked version and I would expect that list to not be long, because we'll refactor it out (hopefully soon).

I filed #652 for tracking this work.