Skip to content
This repository has been archived by the owner on May 4, 2023. It is now read-only.

Let's have a wrapper around libsolc #8

Open
kirushik opened this issue Dec 13, 2017 · 6 comments
Open

Let's have a wrapper around libsolc #8

kirushik opened this issue Dec 13, 2017 · 6 comments

Comments

@kirushik
Copy link
Collaborator

kirushik commented Dec 13, 2017

It will allow us to compile contracts (and extract ABIs) without any need to shell-out to the compiler.
Also will allow some advanced instumentation techniques (like custom opcodes maybe?) for #7

UPD: renamed the issue to follow the @axic suggestion about wrapping.

@snd
Copy link
Contributor

snd commented Dec 18, 2017

where does one find libsolidity? a google search didn't bring up any meaningful results

@kirushik
Copy link
Collaborator Author

kirushik commented Dec 18, 2017

@snd I referred to this: https://github.com/ethereum/solidity/tree/develop/libsolidity
Haven't looked if it exposes all the knobs and levers necessary, though.

@axic
Copy link

axic commented Dec 22, 2017

I'd strongly suggest a wrapper around https://github.com/ethereum/solidity/tree/develop/libsolc (it makes sense with #25) if you really want to go ahead with an unsupported method at the moment - which is binding to the sources directly.

@kirushik kirushik changed the title Let's have a wrapper around libsolidity Let's have a wrapper around libsolc Dec 22, 2017
@kirushik
Copy link
Collaborator Author

@axic while we have you here, maybe you can share you opinion about what's most likely to go wrong if we bind directly to the compiler sources?
Like, I understand that we're voiding all the possible warranties and such (so we won't treat your answer as a compatibility commitment or anything) — but it will definitely help to know our risks upfront.

PS. Thanks for correcting me about libsolidity and libsolc. I should've investigated the options more thoroughly instead of just skimming the repo structure and opening this issue.

@snd
Copy link
Contributor

snd commented Jun 7, 2018

It will allow us to compile contracts (and extract ABIs) without any need to shell-out to the compiler.

personally i don't think shelling out to the compiler is much of a problem

Also will allow some advanced instumentation techniques (like custom opcodes maybe?) for #7

that could be great.
we'll have to weigh up whether it justifies binding to the sources, which is more complex than shelling out

@axic
Copy link

axic commented Jun 12, 2018

@kirushik sorry didn't see this ping :(

Nothing should go wrong really and that API is meant to be stable (but of course no guarantees on that!), however since we don't ship official releases of libsolc, you'd need to find the proper commits and compile the sources directly together with Rust.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@axic @snd @kirushik and others