安装solidity

原文地址
date:20170613

版本号

solidity的版本号命名遵从语义化版本协议。除了正式版本之外，最新的开发版本也是可以使用的。最新的开发版本不保证稳定运行，并且包含未文档化的或者不兼容的变更（?broken changes)。我们推荐使用最新的正式版本。下面的安装程序会选择最新的正式版本。

Remix

如果你想要尝试solidity的智能合约，你可以尝试使用Remix，它不需要安装任何软件。如果你像在离线的时候使用Remix，你可以到这个项目中下载zip包。

npm／nodejs

这是安装solidity最方便的方法。
里边提供了一个平台独立的javascript库，它是由c++源码通过Emscripten转换为javascript的。它可以在项目中直接使用（像Remix一样）。可以参考solc-js项目查看指令。
它也有命令行工具，叫做solcjs，可以通过如下npm命令安装：

npm install -g solc

注意：olcjs的命令行选项与solc是不兼容的。所有与solc一同协作的工具（如geth）在solcjs中是不管用的

Docker

我们提供了编译器最新的docker编译。stable仓库包含的是发行版本，而nightly包含的是不稳定的心功能。

docker run ethereum/solc:stable solc --version

目前，docker容器只包含了编译器可执行程序，所以你还要做些额外的工作，选择源码和输出目录。

二进制安装包

Solidity的二进制安装包可以在这个页面找到。
我们也为Ubuntu系统提供PPAs。如下命令，获取最新的稳定版本：

sudo add-apt-repository ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install solc

如果你想安装最新的开发版本：

sudo add-apt-repository ppa:ethereum/ethereum
sudo add-apt-repository ppa:ethereum/ethereum-dev
sudo apt-get update
sudo apt-get install solc

Linux也有安装包，但是只限开发版本：

pacman -S solidity-git

Homebrew安装，在目前为止还没有编译好的安装包，但是Homebrew可以通过编译源码安装。我们也会马上添加编译好的安装包。

brew update
brew upgrade
brew tap ethereum/ethereum
brew install solidity
brew linkapps solidity

如果你想要获取特定版本的solidity，你可以通过homebrew直接从github安装。
参看github上solidity.rb提交。
查看历史提交，直到找到所需的solidity.rb的源码。然后通过brew安装：

brew unlink solidity
# Install 0.4.8
brew install https://raw.githubusercontent.com/ethereum/homebrew-ethereum/77cce03da9f289e5a3ffe579840d3c5dc0a62717/solidity.rb

我们也为Gentoo linux提供了solidity安装包。通过emerge安装：

demerge ev-lang/solidity

从源码安装

这部分保留，不做翻译，需要的读者直接看原文。

从仓库clone源码

macOS所需环境

windows所需环境

外部依赖库

命令行构建

版本号说明

Solidity的版本号包含四部分：

• 版本号
• 前缀标记，通常是develop.YYYY.MM.DD或者nightly.YYYY.MM.DD
• 通过commit.GITHASH格式提交
• 一些平台和编译器的信息。

如果存在一些本地修改，提交会加上.mod后缀。
语义化版本协议（semantic-versioning，简写Semver）将这些部分结合起来。Solidity的预发行标记和Semver的预发行标记相同，Solidity的提交和平台结合起来成为Semver的构建元数据。
一个正式版本的例子：0.4.8+commit.60cc1668.Emscripten.clang
一个开发版本的例子：0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang

版本号的重要信息

当一个正式版本发行的时候，一个补丁版本的层级也会上升。因为我们假设只有补丁代号部分变化。当更改合并的时候，版本号根据Semver规则变化。最终一个正式版本总是跟随着一个开发版本，但是没有prerelease指示。（？After a release is made, the patch version level is bumped, because we assume that only patch level changes follow. When changes are merged, the version should be bumped according to semver and the severity of the change. Finally, a release is always made with the version of the current nightly build, but without the prerelease specifier.）（ps:这段内容和sematic-versioning有很大关系，但是我对它不了解。）
例如：

1. 0.4.0正式版本发布
2. 最新开发版本是0.4.1
3. 如果没有不兼容的更改，就不对版本号做更改。
4. 如果引入了不兼容的更改，版本号升级为0.5.0
5. 0.5.0 发行版本发布

这个规则同version pragma运行得很好。