I could be wrong here, but it seems to me like you’d want to set this up so that each contract has its own
src/ directory. Here’s an example:
TBH, I’m not sure how the actual entry point into the contract code is detected. The reason I think separate
lib.rs files are necessary is because each contract has its own
config object in the migrations file (e.g.
migrations/2_deploy_contracts.js), and the
deploySecretContract() function provided is writing a single
.txt address file for an individual
config.filename. So if you put two contracts in the same
lib.rs file, currently they would have the same address listed in the
.txt file, which wouldn’t make sense.
For the question of how one contract calls the other, I’m not quite sure how this happens. I assume that there should be a way to pass the first secret contract’s address into the constructor of the second one when doing the migration, and using something similar to
EthContract::new(&contract_addr) (except with a secret contract instead of an
[#eth_contract()] annotation of course), like in the
Voting example here.
Unfortunately I can’t seem to find a similar
[#secret_contract] annotation in the current
eng_wasm_derive library, and the
[#pub_interface] annotation doesn’t seem to be used for that functionality, so hopefully the team can clarify how to do this.