Skip to content
This repository has been archived by the owner on Oct 18, 2022. It is now read-only.

installable solc from popular package managers #24

Open
InoMurko opened this issue Apr 28, 2021 · 4 comments
Open

installable solc from popular package managers #24

InoMurko opened this issue Apr 28, 2021 · 4 comments
Labels
question Further information is requested

Comments

@InoMurko
Copy link

Hey, first and foremost... love your work!

One thing I'd like to see... (willing to work too, but checking if you guys agree with the direction) is support for popular tooling that allows you to install raw binaries, brew and asdf would be my two choices for now. Perhaps for brew, we could add it in the ethereums repo?

But, that does mean that if you'd like to have L1 solc next to L2 solc, you need to differentiate binaries somehow. Is a general name replacement an option? Something like solc -> osolc?
Next, a very small change to the codebase:

diff --git a/solc/CommandLineInterface.cpp b/solc/CommandLineInterface.cpp
index 05b021379..a4d1735ce 100644
--- a/solc/CommandLineInterface.cpp
+++ b/solc/CommandLineInterface.cpp
@@ -231,7 +231,7 @@ static set<string> const g_yulDialectArgs
 static void version()
 {
        sout() <<
-               "solc, the solidity compiler commandline interface" <<
+               "solc, the optimism solidity compiler commandline interface" <<
                endl <<
                "Version: " <<
                dev::solidity::VersionString <<
/usr/local/bin/solc --version
solc, the optimism solidity compiler commandline interface
Version: 0.5.16

Thanks and cheers

@InoMurko
Copy link
Author

One such framework that directly calls solc is https://github.com/compound-finance/saddle

@snario snario added the question Further information is requested label Apr 29, 2021
@ben-chain
Copy link
Contributor

I can look into doing this! @smartcontracts do you know if this requires changes to our solidity plugin? Intuitively it seems like the command changing for the native build would be fine for our stuff, which directly calls the emscripten binaries, but I'm not positive.

@InoMurko
Copy link
Author

awesome @ben-chain lemme know if I can help in any way!

@smartcontracts
Copy link
Contributor

Intuitively it seems like the command changing for the native build would be fine for our stuff, which directly calls the emscripten binaries, but I'm not positive.

I think you're correct. Don't think this would impact our plugins.

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

No branches or pull requests

4 participants