Consider making libsolc a public API and ship shared libraries on Linux/macOS releases

[axic]

This was discussed in #2255 earlier. #2864 cleaned up the public API.

[christianparpart]

I'm all in for this idea, as it might potentially help tooling integration, such as in IDEs for code completion (at some point in time).

[axic]

After 0.5.0 there should be no blocker from the API side. It is quite clean now.

[axic]

I think effectively it is kind of public since 0.5.0. With 0.6.0 the interface will be even more cleaner.

Evidenced by having solc-js and solc-rust as consumers.

The question here remains about shipping a statically linked shared library as part of the release.

[axic]

Since now we are shipping Linux and macOS release binaries under solc-bin, perhaps we should reconsider this question here. cc @cameel @chriseth

[cameel]

Are we building this lib anywhere in a form that's suitable for release? If it's already possible to get it, it would just be a matter of @chriseth uploading it to the release page along with the rest of binaries (which currently come from Travis as far as I know). Then I'd just have to add a new dir in solc-bin.

Otherwise we might want to use github actions to building it from the start (@ekpyron would probably be interested).

[ekpyron]

So far we don't build such a library anywhere (the build system doesn't even support doing so) - but we could indeed think about changing that. If we did that, I'd actually consider splitting the command line interface and libsolc entirely (making the CLI a thin executable linking against libsolc and interacting with it via its exported API and standard-json), even though that'd be some more work.

[axic]

We are already building the libsolc library in the build system: soljson, the emscripten target, is exactly that :)

[ekpyron]

Yeah, of course, I meant except that one :-).
(EDIT: and build system-wise the emscripten builds are quite special anyways - soljson.js is still actually linked as executable and not as shared library - and emscripten has custom cmake logic in general)

[ekpyron]

In any case: the current CLI in solc/* is a huge mess anyways - so I'd actually say it would be rather nice to rewrite it as a thin frontend to the standard-json backend that can then generally be provided as shared library...

[chriseth]

Before we invest time in this: What would be a user of that library? Wouldn't it be better to implement a language server instead?

[gakonst]

A user of this library would be consumers that want to FFI to it, e.g. for building high performance tooling in other languages. See here for why one would want native bindings.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.