Conan recipe for simplifying build and install of solidity

[redradist]

Abstract

In C++ community we already have nice tool like conan.
It could simplify installation of solidity as simple as:

conan install solidity/1.0.0@

Motivation

Simplifying build and install of solidity

[cameel]

Do you mean distributing the solc executable via conan? It's an interesting idea, though I'm not sure using conan this way actually solves any practical problem. Getting the compiler is already as simple as downloading a statically linked binary from https://binaries.soliditylang.org so this would not simplify anything unless you're already using conan and even then it's not that much of a simplification. The compiler is most often used indirectly, via frameworks like Truffle, Hardhat, Brownie, dapp-tools, etc and they already have built-in mechanisms for downloading the binaries and managing different versions. I doubt they would be switching to getting it via conan.

This would be much more useful if we had libsolc as proposed in #5306 but there has not been too much progress on that. Once we do have it though, I agree that conan would be a good option to distribute the library in a way that makes it easy to use in other C++ projects. The question is though - why specifically conan and not e.g. Hunter or vcpkg?

Finally, a prerequisite to distribute via conan would probably be to make it possible for the compiler to use dependencies from there so we should do that first. I think this would actually be a good way to solve #8860.

[redradist]

@cameel

Do you mean distributing the solc executable via conan?

Yeah

This would be much more useful if we had libsolc as proposed in #5306 but there has not been too much progress on that. Once we do have it though, I agree that conan would be a good option to distribute the library in a way that makes it easy to use in other C++ projects.

Yeah, probable it would be even more interesting ...

... The question is though - why specifically conan and not e.g. Hunter or vcpkg?

Because conan support projects not only built on cmake tool, but it also supports make, meson and so on

[cameel]

Because conan support projects not only built on cmake tool, but it also supports make, meson and so on

We don't really support anything other than cmake though so does that really matter for solc? I mean, I definitely do like the idea of conan more than e.g. vcpkg which seems to be tied more to MS ecosystem but would be nice to have some more concrete reasons for choosing this particular package manager over others :) AFAIK there's no clear winner yet and all of them are good candidates to become the standard tooling.

In any case, I do like the idea of supporting it as one of the ways to get dependencies. I have just added a comment proposing it in #8860. Once we get that, we can think about publishing solc there.

[redradist]

@cameel

Because conan support projects not only built on cmake tool, but it also supports make, meson and so on

We don't really support anything other than cmake though so does that really matter for solc? I mean, I definitely do like the idea of conan more than e.g. vcpkg which seems to be tied more to MS ecosystem but would be nice to have some more concrete reasons for choosing this particular package manager over others :) AFAIK there's no clear winner yet and all of them are good candidates to become the standard tooling.

More build systems means more good libraries that you potentially could add as dependencies to your project without pain

[chriseth]

I personally think adding a library is never without pain, you always take on the responsibility of bugs in those libraries yourself.

[redradist]

@chriseth

I personally think adding a library is never without pain, you always take on the responsibility of bugs in those libraries yourself.

Without pain of compilation

[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.