Using `std` package without exports for target=`wasm32`

[kromsten]

When a project references cosmwasm_std crate as one of the dependencies and is being compiled to wasm32 architecture, the package injects entrypoint exports into the final wasm build

cosmwasm/packages/std/src/lib.rs

Lines 111 to 112 in 888552a

	#[cfg(target_arch = "wasm32")]
	pub use crate::exports::{do_execute, do_instantiate, do_migrate, do_query, do_reply, do_sudo};

It might not be desirable when developing interfaces and libraries that only need certain types like Binary, Uint128and so on.

It unnecessarily increases the size when building for Javascript environment and causes issues when building for virtual machines with custom constraints

A possible solution would be to only inject the exports when referencing cosmwasm contract specific entities like entrypoint or to provide additional feature flag for the crate (e.g. library) for opting out of injection

[webmaster128]

Good point. I thought about this from time to time too in the past but it was never a priority to fix. Could be done using a macro you need to call explicitly from a contract.

Could you explain the use case in mode detail, specially the envorinment you want to use this in and the goal of your project? So far all JavaScript usage is clients and they don't really need the types as Addr, Uint128 and Binary are simply strings in the JSON interface.

[webmaster128]

Also is your problem exports or imports?

• Exports is functionality provided by the contract to the env (e.g. allocate, requires_iterator, execute)
• Imports is something the contact requires from the host (e.g. abort, secp256k1_verify)

[kromsten]

The javascript issue is indeed not of higher priority. Compiling for javascript solely for porting the primitives wouldn't make sense for sure. However if it was a library that uses those primitives for an algorithm or a complex function it can be beneficial to use the same code in multiple environments. Possible some performance improvements for JS if it is doing cryptography or matrix calculations

What I am personally face right now is issues caused by referencing an interface package that depends on cosmwam-std and trying to compile it for a different virtual machine.

Here is a package I am trying to reference but I believe it is going to be identical with cw1 it is extending or any other package for that matter

If I try to reference the package from a project that uses a fork of the cosmwasm it will fail since both of the version are injecting the same exports on build (on target_arch = wasm32)

note: rust-lld: error: duplicate symbol: interface_version_8
          >>> defined in /project_path/target/wasm32-unknown-unknown/release/deps/libsecret_cosmwasm_std-c4688300c5c7376b.rlib(secret_cosmwasm_std-c4688300c5c7376b.secret_cosmwasm_std.ad677aa44ba95ce7-cgu.14.rcgu.o)
          >>> defined in /project_path/target/wasm32-unknown-unknown/release/deps/libcosmwasm_std-c39caa4aaadbfe82.rlib(cosmwasm_std-c39caa4aaadbfe82.cosmwasm_std.6539afbd309a16f9-cgu.04.rcgu.o)
          
note: rust-lld: error: duplicate symbol: allocate
     ***
note: rust-lld: error: duplicate symbol: deallocate
     ***

[webmaster128]

Building on top of #2468 I tried to use a macro a la cosmwasm_std::setup_contract!(); in the lib.rs of the contract that would explicitly enable the imports and exports for one particular version of cosmwasm_std. However, this would lead to inlining all of the imports/expors/memory code into the contract's namespace. This would be hard to maintain but still possible. But then we also break #[entry_point] which requires e.g. cosmwasm_std::do_query to be a public export. We would need to adapt #[entry_point] to search those exports in crate:: instead. But then we have features like ibc2 that conditionally enable exports. Moving the exports to the crate means ibc2 needs to become a feature of the contract instead of cosmwasm-std or an argument to the cosmwasm_std::setup_contract!(); macro.

I think the whole approach can work, but if we go down that path we would be building a massive code generator to inline the right things in the contract crate.

A solution closer to what we already have is a new "exports" feature which enables the code inside of cosmwasm_std that we need. Library developers than need to ensure that they don't enable this (default?) feature. But that's best practice anyways.