نسخه های Solidity از نسخه سینتکسی پیروی میکنند. علاوه بر این، نسخههای موقتی با نسخه اصلی 0 (مانند 0.x.y) حاوی تغییرات شکستن نیستند.
نسخه های Solidity از نسخه سینتکسی پیروی میکنند. علاوه بر این، نسخههای موقتی با نسخه اصلی 0 (مانند 0.x.y) حاوی تغییرات شکستن نیستند. این بدان معناست که کدی که با نسخه 0.x.y کامپایل میشود، انتظار میرود که با.x.z 0 در جایی که z > y کامپایل شود. علاوه بر نسخههای منتشر شده، ساختهای توسعه شبانه را با این هدف ارائه میکنیم که توسعه دهندگان بتوانند ویژگیهای آتی را امتحان کنند و بازخورد اولیه را ارائه کنند. با این حال، توجه داشته باشید که در حالی که ساختهای شبانه معمولاً بسیار پایدار هستند، حاوی کد bleeding-edge از شاخه توسعه هستند و تضمین نمیشود که همیشه کار کنند. علیرغم بهترین تلاشهای ما، ممکن است آنها حاوی تغییرات غیرمستند و/یا شکسته باشند که بخشی از نسخه واقعی نخواهد بود. آنها برای استفاده تولیدی در نظر گرفته نشدهاند.
هنگام استقرار قراردادها، باید از آخرین نسخه منتشر شده Solidity استفاده کنید. این به این دلیل است که تغییرات شکستن (breaking)، و همچنین ویژگی های جدید و رفع اشکال به طور منظم معرفی میشوند. ما در حال حاضر از شماره نسخه 0.x برای نشان دادن این سرعت سریع تغییر استفاده میکنیم.
پیشنهاد ویژه: آموزش سالیدیتی
ما Remix را برای قراردادهای کوچک و برای یادگیری سریع Solidity توصیه میکنیم. برای دسترسی به ریمیکس آنلاین، نیازی به نصب چیزی ندارید. اگر میخواهید بدون اتصال به اینترنت از آن استفاده کنید، به آدرس زیر مراجعه کنید:
https://github.com/ethereum/remix-live/tree/gh-pages، فایل zip. را همانطور که در آن صفحه توضیح داده شده است دانلود کنید. Remix همچنین یک گزینه مناسب برای آزمایش نسخههای شبانه بدون نصب چندین نسخه Solidity است.
گزینههای بیشتر در این صفحه، جزئیات نصب نرم افزار کامپایلر Solidity از طریق commandline را بر روی رایانه شما شرح میدهد. اگر روی یک قرارداد بزرگتر کار میکنید یا اگر به گزینههای کامپایل بیشتری نیاز دارید، یک کامپایلر خط فرمان را انتخاب کنید.
از npm به عنوان یک روش راحت برای نصب solcjs استفاده کنید. برنامه solcjs دارای ویژگیهای کمتری نسبت به راههای دسترسی به کامپایلر است که در ادامه این صفحه توضیح داده شده است. استفاده از مستندات Commandline Compiler فرض میکند که شما از کامپایلر کامل solc استفاده میکنید. استفاده از solcjs در مخزن خودش مستند شده است.
توجه داشته باشید: پروژه solc-js از C++ solc با استفاده از Emscripten مشتق شده است، به این معنی که هر دو از کد منبع کامپایلر یکسانی استفاده میکنند. solc-jsرا میتوان مستقیماً در پروژههای جاوا اسکریپت (مانند ریمیکس) استفاده کرد. لطفاً به مخزن solc-js برای مشاهده دستورات مراجعه کنید.
npm install -g solc
توجه داشته باشید
خط فرمان اجرایی solcjs نام دارد. گزینههای خط فرمان solcjs با solc سازگار نیستند و ابزارها (مانند geth ) انتظار دارند رفتار solc با solcjs کار نکند.
تصاویر داکر از نسخه های سالیدیتی با استفاده از تصویر solc از سازمان ethereum در دسترس است. از برچسبهای stable برای آخرین نسخه منتشر شده و nightly برای تغییرات احتمالی ناپایدار در بخشهای نسخه استفاده میکند. تصویر داکر کامپایلر اجرایی را میکند، بنابراین میتوانید تمام آرگومانهای کامپایلر را به آن منتقل کنید. به عنوان مثال، دستور زیر نسخه پایدار تصویر solc را در یک محفظه (container) جدید اجرا میکند و آرگومان help– را میدهد.
docker run ethereum/solc:stable --help
همچنین میتوانید نسخههایِ توسعهِ منتشر شده را با برچسب مشخص کنید، به عنوان مثال، برای نسخه 0.5.4.
docker run ethereum/solc:0.5.4 --help
برای استفاده از تصویر داکر برای کامپایل فایلهای سالیدیتی در دستگاه میزبان، یک پوشه محلی برای ورودی و خروجی نصب کرده و قرارداد کامپایل را مشخص کنید. برای مثال:
docker run -v /local/path:/sources ethereum/solc:stable -o /sources/output --abi --bin /sources/Contract.sol
شما همچنین می توانید از رابط استاندارد JSON (که در هنگام استفاده از کامپایلر با ابزار توصیه می شود) استفاده کنید. هنگام استفاده از این رابط، تا زمانی که ورودی JSON مستقل باشد، لازم نیست هیچ دایرکتوری را نصب کنید (یعنی به هیچ فایل خارجی که باید با فراخوانی وارد کردن بارگیری شود، اشاره نمی کند).
docker run ethereum/solc:stable --standard-json < input.json > output.json
سته های باینری Solidity در solidity/releases موجود هستند.
ما همچنین PPAs برای Ubuntuداریم، می توانید آخرین نسخه پایدار را با استفاده از دستورات زیر دریافت کنید
sudo add-apt-repository ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install solc
نسخه شبانه (nightly ) را میتوان با استفاده از این دستورات زیر نصب کرد:
sudo add-apt-repository ppa:ethereum/ethereum
sudo add-apt-repository ppa:ethereum/ethereum-dev
sudo apt-get update
sudo apt-get install solc
علاوه بر این، برخی از توزیع های لینوکس بسته های خود را ارائه می دهند. این بسته ها مستقیماً توسط ما نگهداری نمی شوند، اما معمولاً توسط نگهبانان بسته مربوطه به روز می شوند.
به عنوان مثال، Arch Linux دارای بسته هایی برای آخرین نسخه توسعه است:
pacman -S solidity
ما همچنین یک بسته اسنپ را منتشر میکنیم که در همه توزیعهای پشتیبانی شده لینوکس قابل نصب است. برای نصب آخرین نسخه پایدار solc:
sudo snap install solc
اگر میخواهید آخرین نسخه توسعه دهنده سالیدیتی را با جدیدترین تغییرات آزمایش کنید، لطفاً از مورد زیر استفاده کنید:
sudo snap install solc --edge
توجه داشته باشید
اسنپ solc از سختگیری شدید استفاده میکند. این حالت امنترین حالت برای بستههای فوری است اما با محدودیتهایی همراه است، مثلاً شما فقط به فایلهای موجود در دایرکتوریهای /home و /media دسترسی خواهید داشت. برای کسب اطلاعات بیشتر، به Demystifying Snap Confinement مراجعه کنید.
ما کامپایلر سالیدیتی را از طریق هومبرو به عنوان نسخهِ ساخته شده از منبع توزیع میکنیم. مخزنهای از پیش ساخته شده در حال حاضر پشتیبانی نمیشوند.
brew update
brew upgrade
brew tap ethereum/ethereum
brew install solidity
برای نصب جدیدترین نسخه سالیدیتی 0.5.x/0.4.xمیتوانید به ترتیب از brew install solidity@4 و brew install solidity@5 استفاده کنید. اگر به نسخه خاصی از سالیدیتی نیاز دارید، میتوانید فرمول هومبرو را مستقیماً از گیتهاب نصب کنید. لینک solidity.rb commits on Github را مشاهده کنید.
هشِ کامیتهای نسخه موردنظر خود را کپی کرده و در دستگاه خود بررسی کنید.
git clone https://github.com/ethereum/homebrew-ethereum.git
cd homebrew-ethereum
git checkout <your-hash-goes-here>
با استفاده از brew آن را نصب کنید:
brew unlink solidity
# برای مثال، نصب نسخه 0.4.8
brew install solidity.rb
ما یک مخزن حاوی نسخههای استاتیک از نسخههای کامپایلر قبلی و فعلی را برای همه پلتفرمهای پشتیبانی شده در solc-bin نگهداری میکنیم. این مکان همچنین مکانی است که میتوانید نسخههای شبانه را در آن پیدا کنید.
مخزن نه تنها راهی سریع و آسان برای کاربران نهایی است تا باینریها را برای استفاده در خارج از جعبه آماده کنند، بلکه به معنای مناسب بودن با ابزارهای ثالث است:
همین فایلهای باینری در بیشتر موارد در صفحه انتشارات سالیدیتی در گیتهاب موجود است. تفاوت در این است که ما به طور کلی نسخههای قدیمی را در صفحه انتشار گیتهاب به روز نمیکنیم. این بدان معناست که در صورت تغییر شرایط نامگذاری، نام آنها را تغییر نمیدهیم و برای پلتفرمهایی که در زمان انتشار پشتیبانی نمیشوند، نسخههایی اضافه نمیکنیم. این امر فقط در solc-bin اتفاق میافتد.
مخزن solc-bin شامل چندین دایرکتوری سطح بالا است که هر یک نمایانگر یک پلتفرم واحد میباشد. هر یک شامل یک فایل list.json است که فایلهای باینری موجود را فهرست میکند. برای مثال در emscripten-wasm32/list.json اطلاعات زیر را در مورد نسخه 0.7.4 خواهید یافت:
هشدار
به دلیل نیاز به سازگاری زیاد، مخزن حاوی برخی از عناصر قدیمی میباشد، اما هنگام نوشتن ابزارهای جدید نباید از آنها استفاده کنید:
اگر میخواهید بهترین عملکرد را داشته باشید، از emscripten-wasm32/ (با جایگزینی برای emscripten-asmjs/) به جای bin/ استفاده کنید. ما تا نسخه 0.6.1 فقط فایلهای باینری asm.js را ارائه میدادیم. با شروع 0.6.2، ما به WebAssembly builds به عملکرد بسیار بهتر روی آوردیم. ما نسخههای قدیمی تر را برای wasm بازسازی کردهایم اما فایلهای اصلی asm.js در bin/ باقی میمانند. موارد جدید باید در یک فهرست جداگانه قرار داده شوند تا از تصادم نامی جلوگیری شود.
{
"path": "solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js",
"version": "0.7.4",
"build": "commit.3f05b770",
"longVersion": "0.7.4+commit.3f05b770",
"keccak256": "0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3",
"sha256": "0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2",
"urls": [
"bzzr://16c5f09109c793db99fe35f037c6092b061bd39260ee7a677c8a97f18c955ab1",
"dweb:/ipfs/QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS"
]
}
این بدان معناست که:
هشدار
به دلیل نیاز به سازگاری زیاد، مخزن حاوی برخی از عناصر قدیمی میباشد، اما هنگام نوشتن ابزارهای جدید نباید از آنها استفاده کنید:
هشدار
فایلهای باینری نیز در https://ethereum.github.io/solc-bin در دسترس هستند، اما این صفحه به روز رسانی خود را پس از انتشار نسخه 0.7.2 متوقف کرد، هیچ نسخه جدید یا نسخه شبانه برای هر پلتفرمی دریافت نمیکند و ساختار دایرکتوری جدید، از جمله ساختارهای غیر emscripten را ارائه نمیدهد.
اگر از آن استفاده میکنید، لطفاً به لینک زیر مراجعه کنید . https://binaries.soliditylang.org مراجعه کنید، که یک جایگزینی رها کردن است. این به ما امکان میدهد تا به طور شفاف در میزبانی اصلی تغییراتی ایجاد کرده و اختلال را به حداقل برسانیم. بر خلاف دامنه ethereum.github.io ، که ما هیچ کنترلی بر آن نداریم، کار کردن binaries.soliditylang.org تضمین میشود و در دراز مدت همان URL را حفظ کند.
وابستگی های زیر برای همه ساخت های Solidity هستند:
Software | Notes |
---|---|
CMake (version 3.13+) | Cross-platform build file generator. |
Boost (version 1.77+ on Windows, 1.65+ otherwise) | C++ libraries. |
Git | Command-line tool for retrieving source code. |
z3 (version 4.8+, Optional) | For use with SMT checker. |
cvc4 (Optional) | For use with SMT checker. |
توجه داشته باشید
نسخههای سالیدیتی قبل از 0.5.10 نمیتوانند به درستی با نسخههای Boost 1.70+ لینک شوند. یک راه حل ممکن این است که قبل از اجرای دستور cmake برای پیکربندی سالیدیتی، Boost install path>/lib/cmake/Boost-1.70.0> را به طور موقت تغییر نام دهید.
با شروع از 0.5.10 لینک کردن برخلاف Boost 1.70+ باید بدون دخالت دستی کار کند.
توجه داشته باشید
پیکربندی پیشفرض ساخت به یک نسخه خاص Z3 نیاز دارد (آخرین نسخه در زمان آخرین بهروزرسانی کد). تغییرات ایجاد شده بین نسخه های Z3 اغلب منجر به بازگشت نتایج کمی متفاوت (اما هنوز معتبر) می شود. تستهای SMT ما این تفاوتها را در نظر نمیگیرند و احتمالاً با نسخهای متفاوت از نسخهای که برای آن نوشته شدهاند شکست خواهند خورد. این بدان معنا نیست که ساختی که از نسخه دیگری استفاده می کند معیوب است. اگر گزینه DSTRICT_Z3_VERSION=OFF – را به CMake منتقل کنید، میتوانید با هر نسخهای که نیاز ارائه شده در جدول بالا را برآورده میکند، بسازید. با این حال، اگر این کار را انجام می دهید، لطفاً به یاد داشته باشید که گزینه no-smt– را به scripts/tests.sh بفرستید تا از تست های SMT رد شوید .
توجه داشته باشید
به طور پیشفرض ساخت در حالت pedantic انجام میشود، که هشدارهای اضافی را فعال میکند و به کامپایلر میگوید که همه هشدارها را به عنوان خطا در نظر بگیرد. این امر توسعهدهندگان را مجبور میکند تا هشدارها را بهموقع اصلاح کنند، بنابراین آنها جمعآوری نمیشوند تا بعداً رفع شوند. اگر فقط علاقه مند به ایجاد نسخه انتشار هستید و قصد ندارید کد منبع را برای مقابله با چنین هشدارهایی تغییر دهید، می توانید گزینه DPEDANTIC=OFF- را به CMake برای غیرفعال کردن این حالت منتقل کنید. انجام این کار برای استفاده عمومی توصیه نمی شود، اما ممکن است زمانی که از زنجیره ابزاری استفاده می کنیم که با آن آزمایش نمی کنیم یا در تلاش برای ساخت نسخه قدیمی با ابزارهای جدیدتر هستیم، ضروری باشد. اگر با چنین هشدارهایی مواجه شدید، لطفاً آنها را گزارش دهید.
کامپایلرهای C++ زیر و حداقل نسخههای آنها میتوانند پایگاه کد سالیدیتی را ایجاد کنند:
برای نسخههای مکاو اس، مطمئن شوید که آخرین نسخه Xcode را نصب کردهاید. این شامل کامپایلر Clang C++ ، Xcode IDE و سایر ابزارهای توسعه اپل میباشد که برای ایجاد برنامههای ++ C در OS X مورد نیاز است. اگر برای اولین بار Xcode را نصب میکنید یا نسخه جدیدی را نصب کردهاید، باید قبل از توسعه، با لایسنس موافقت کنید تا بتوانید با خط فرمان، توسعهها را انجام دهید:
sudo xcodebuild -license accept
اسکریپت نسخه OS X ما، از مدیریت بسته Homebrew برای نصب نیازمندیهای خارجی استفاده میکند. اگر میخواهید دوباره از ابتدا شروع کنید، در اینجا نحوه uninstall Homebrew ذکر شدهاست.
شما باید وابستگیهای زیر را برای نسخههای ویندوز برای سالیدیتی نصب کنید:
Software | Notes |
---|---|
Visual Studio 2019 Build Tools | C++ compiler |
Visual Studio 2019 (Optional) | C++ compiler and dev environment. |
Boost (version 1.77+) | C++ libraries. |
اگر از قبل یک ویرایشگر دارید و فقط به کامپایلر و کتابخانه نیاز دارید، میتوانید ابزارهای نسخه 2019 ویژوال استودیو را نصب کنید.
ویژوال استودیو 2019 هم ویرایشگر و هم کامپایلر و کتابخانههای لازم را ارائه میدهد. بنابراین اگر ویرایشگر ندارید و ترجیح میدهید سالیدیتی را توسعه دهید، ویژوال استودیو 2019 ممکن است یک انتخاب مناسب برای شما باشد تا همه چیز را به راحتی راه اندازی کنید.
در اینجا لیستی از اجزایی که باید در ابزارهای نسخه ویژوال استودیو 2019 نصب شود، آورده شدهاست:
ما یک اسکریپت کمکی داریم که می توانید از آن برای نصب تمام وابستگی های خارجی مورد نیاز استفاده کنید:
scripts\install_deps.ps1
با این کار boost و cmake در زیر شاخه deps نصب می شود.
برای کلون کردن کد منبع، دستور زیر را اجرا کنید:
git clone --recursive https://github.com/ethereum/solidity.git
cd solidity
اگر میخواهید به توسعه سالیدیتی کمک کنید، باید سالیدیتی را فورک کنید و فورک شخصی خود را به عنوان ریموت دوم اضافه کنید:
git remote add personal git@github.com:[username]/solidity.git
توجه داشته باشید
این روش منجر به نسخه پیش انتشار میشود که به عنوان مثال یک فَلگ در هر کد بایتی که توسط چنین کامپایلری تولید میشود، تنظیم میشود. اگر میخواهید کامپایلر سالیدیتی منتشر شده را دوباره توسعه دهید، لطفاً از tarball منبع در صفحه انتشار گیتهاب استفاده کنید:
https://github.com/ethereum/solidity/releases/download/v0.X.Y/solidity_0.X.Y.tar.gz
(“کد منبع” ارائه شده توسط github نیست.)
قبل از ساخت حتما وابستگیهای خارجی (External Dependencies) را نصب کنید (به بالا مراجعه کنید).
پروژه Solidity از CMake برای پیکربندی ساخت استفاده میکند. ممکن است بخواهید ccache را برای سرعت بخشیدن به ساخت های مکرر نصب کنید. CMake آن را به طور خودکار دریافت می کند. Building Solidity در لینوکس، macOS و سایر Unice ها کاملاً مشابه است:
mkdir build
cd build
cmake .. && make
یا حتی در لینوکس و مکاو اس راحتتر، میتوانید اجرا کنید:
# Note: This will install binaries solc and soltest at /usr/local/bin
./scripts/build.sh
هشدار
ساختهای BSD باید کار کنند، اما توسط تیم Solidity آزمایش نشدهاند.
mkdir build
cd build
cmake -G "Visual Studio 16 2019" ..
در صورت تمایل به استفاده از نسخه boost نصب شده توسط اسکریپت scripts\install_deps.ps1 ،علاوه بر این باید “*-DBoost_DIR=”deps\boost\lib\cmake\Boost- و DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded را به عنوان آرگومان برای فراخوانی cmakeارسال کنید. این عمل باید منجر به ایجاد solidity.sln در آن نسخه دایرکتوری شود. دو بار کلیک بر روی آن فایل باعث میشود تا ویژوال استودیو روشن شود. ما ساخت پیکربندی انتشار (Release) را پیشنهاد میکنیم، اما بقیه نیز کار میکنند.
از سوی دیگر، شما میتوانید برای ویندوز روی خط فرمان بسازید ، مانند این:
cmake --build . --config Release
اگر علاقه دارید که چه گزینههای CMake در دسترس هستند، cmake .. -LH را اجرا کنید.
سالیدیتی را میتوان در کنار حل کنندههای SMT ایجاد کرد و در صورت یافتن آنها در سیستم به طور پیش فرض این کار را انجام میدهد. هر حل کننده را میتوان با گزینه cmake غیرفعال کرد.
توجه: در برخی موارد ، این نیز می تواند یک راه حل احتمالی برای خرابی نسخه باشد.
در داخل پوشه build میتوانید آنها را غیرفعال کنید، زیرا به طور پیش فرض فعال هستند:
# Disables only Z3 SMT Solver
cmake .. -DUSE_Z3=OFF
# Disables only CVC4 SMT Solver
cmake .. -DUSE_CVC4=OFF
# Disables both Z3 and CVC4
cmake .. -DUSE_CVC4=OFF -DUSE_Z3=OFF
رشته نسخه با جزئیات
اگر تغییرات محلی وجود داشته باشد، کامیتها با mod. پسوند داده میشود.این قطعات طبق نیاز Semver ترکیب میشوند، جایی که برچسب پیش از انتشار سالیدیتی برابر است با پیش از انتشار Semver و کامیت سالیدیتی و پلتفرم ترکیبی فراداده توسعه Semver را تشکیل میدهند.
A release example: 0.4.8+commit.60cc1668.Emscripten.clang.
A pre-release example: 0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang
اطلاعات مهم در مورد نسخه بندی
پس از انتشار، سطح نسخه پَچ بامپ شده است، زیرا ما فرض میکنیم که فقط تغییرات سطح پَچ دنبال میشود. وقتی تغییرات ادغام میشوند، نسخه باید با توجه به semver و شدت تغییرات بامپ شود. سرانجام، همیشه نسخهای از نسخه فعلی شبانه منتشر میشود، اما بدون تعیین .prerelease
مثال:
این رفتار با نسخه پراگما به خوبی کار میکند.