Then compile_package_no_exit is called from BuiltPackage::build() here which then runs extended_checks and apparently injects metadata of some sort. (Not holding the PackageLock, btw.)
Meanwhile, compile_package is called from various tests and CLIs (coverage.rs in both third_party and aptos/src/move_tool/, disassemble.rs in third_party/move/tools/move-cli).
It's not clear whether PackageLock is needed around extended_checks and metadata. It's also possible it's too confining, and is obstructing parallel builds or what.
🐛 Bug
Compiled bytecode output is apparently written by function save_to_disk. https://github.com/aptos-labs/aptos-core/blob/211fcdaf1abfa01561cdab79ab00a68a5ec2[…]rty/move/tools/move-package/src/compilation/compiled_package.rs
It is called from compile_package and compile_package_no_exit etc., here https://github.com/aptos-labs/aptos-core/blob/1a639a9cc3c21a447ce5031c6241a21ea6fb02ed/third_party/move/tools/move-package/src/lib.rs#L202, while holding a PackageLock.
Then compile_package_no_exit is called from BuiltPackage::build() here which then runs extended_checks and apparently injects metadata of some sort. (Not holding the PackageLock, btw.)
Meanwhile, compile_package is called from various tests and CLIs (coverage.rs in both third_party and aptos/src/move_tool/, disassemble.rs in third_party/move/tools/move-cli).
It's not clear whether PackageLock is needed around extended_checks and metadata. It's also possible it's too confining, and is obstructing parallel builds or what.
This needs more study.