You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the custom LLVM fork should only be necessary for the Solana backend, we should decouple the substrate backend. Otherwise anyone wanting to use solang as a library is forced to use the solana labs LLVM fork, even though they might not want to build SBF contracts at all.
Ideally the code base and build scripts can be controlled with a solana or SBF feature flag.
The text was updated successfully, but these errors were encountered:
Solang is built on top of LLVM. Even if we decouple from Solana's LLVM fork, developers need LLVM installed locally. The LLVM libraries are only necessary for building Solang from source. The binaries we make available in our releases page are statically linked to LLVM, so no need to download anything.
(ACK, but what I meant is we should have a way to say "I want use Solang as a crate and I only care for the Substrate target" and it will work with vanilla LLVM. Otherwise, people will need the Solana labs LLVM fork as soon as they depend on Solang, even if they don't wanna build SBF contracts, which seems very odd)
If you use upstream llvm, cargo test will on Substrate due to the linker not being re-entrant. Maybe that's been fixed in the latest llvm, I haven't looked at this for ages.
Since the custom LLVM fork should only be necessary for the Solana backend, we should decouple the substrate backend. Otherwise anyone wanting to use solang as a library is forced to use the solana labs LLVM fork, even though they might not want to build SBF contracts at all.
Ideally the code base and build scripts can be controlled with a
solana
orSBF
feature flag.The text was updated successfully, but these errors were encountered: