نصب کامپایلر سالیدیتی

نسخه بندی

نسخه های 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 / Node.js

از 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
# eg. Install 0.4.8
brew install solidity.rb

باینری‌های استاتیک

ما یک مخزن حاوی نسخه‌های استاتیک از نسخه‌های کامپایلر قبلی و فعلی را برای همه پلتفرم‌های پشتیبانی شده در solc-bin نگهداری می‌کنیم. این مکان همچنین مکانی است که می‌توانید نسخه‌های شبانه را در آن پیدا کنید.

مخزن نه تنها راهی سریع و آسان برای کاربران نهایی است تا باینری‌ها را برای استفاده در خارج از جعبه آماده کنند، بلکه به معنای مناسب بودن با ابزارهای ثالث است:

  • محتوا در https://binaries.soliditylang.org قرارداده شده ‌است که در آن می‌توان به راحتی از طریق HTTPS بدون احراز هویت، محدودیت سرعت یا نیاز به استفاده از git بارگیری کرد.
  • محتوا با هدرهای صحیح، نوع محتوا و با پیکربندی CORS ارائه می‌شود تا بتواند مستقیماً توسط ابزارهایی که در مرورگر اجرا می‌شوند بارگیری شود.
  • فایل‌های باینری نیازی به نصب یا باز کردن بسته بندی ندارند (به استثنای نسخه‌های قدیمی ویندوز که همراه با DLLهای ضروری هستند.)
  • ما برای سطح بالایی از سازگاری با گذشته تلاش می‌کنیم. فایل‌ها، پس از اضافه شدن، بدون ارائه پیوند تغییر مسیر در مکان قدیمی حذف یا منتقل نمی‌شوند. همچنین هرگز در محل خود تغییر داده نمی‌شوند و همیشه باید با چک‌سام اصلی مطابقت داشته باشند. تنها استثناء‌ می‌تواند فایل‌های شکسته یا غیرقابل استفاده باشد که اگر به همین صورت باقی بمانند، می‌توانند بیشتر از فایده باعث آسیب شوند.
  • فایل‌ها از طریق HTTP و HTTPS ارائه می‌شوند. تا زمانیکه لیست فایل‌ها را به صورت ایمن (از طریق git ،HTTPS ، IPFS یا به صورت محلی ذخیره کردید) به دست آوردید. و پس از بارگیری، فایل‌های هش باینری را تأیید کنید. لازم نیست از HTTPS برای خود فایل‌های باینری استفاده کنید.

همین فایل‌های باینری در بیشتر موارد در صفحه انتشارات سالیدیتی در گیت‌هاب موجود است. تفاوت در این است که ما به طور کلی نسخه‌های قدیمی را در صفحه انتشار گیتهاب به روز نمی‌کنیم. این بدان معناست که در صورت تغییر شرایط نامگذاری، نام آن‌ها را تغییر نمی‌دهیم و برای پلتفرم‌هایی که در زمان انتشار پشتیبانی نمی‌شوند، نسخه‌‌هایی اضافه نمی‌کنیم. این امر فقط در 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"
  ]
}

این بدان معناست که:

  • شما می‌توانید باینری را در همان فهرست با نام solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js پیدا کنید. توجه داشته باشید که فایل ممکن است یک پیوند باشد و اگر از گیت برای بارگیری آن استفاده نمی‌کنید یا سیستم فایل شما از پیوند‌ها پشتیبانی نمی‌کند، باید خودتان آن را حل کنید.
  • باینری نیز درلینک زیر قرار داده شده است. در این حالت گیت ضروری نمی‌باشد. و پیوندها، یا با ارائه یک کپی از فایل یا با بازگرداندن یک مسیر HTTP به طور شفاف حل می‌شوند. https://binaries.soliditylang.org/emscripten-wasm32/solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js
  • این فایل همچنین در IPFS در لینک زیر موجود است. QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS
  • ممکن است فایل در آینده در Swarm با شماره c5f09109c793db99fe35f037c6092b061bd39260ee7a677c8a97f18c955ab1 16 موجود باشد
  • با مقایسه هش keccak256 آن با 0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3 می‌توانید صحت باینری را بررسی کنید. هش را می‌توان در خط فرمان با استفاده از ابزار keccak256sumمحاسبه کرد که توسط تابع sha3sum یا keccak256() function from ethereumjs-util در جاوااسکریپت ارائه شده ‌است.

همچنین می‌توانید یکپارچگی باینری را با مقایسه هش sha256 آن با 0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2 تأیید کنید.

هشدار

به دلیل نیاز به سازگاری زیاد، مخزن حاوی برخی از عناصر قدیمی می‌باشد، اما هنگام نوشتن ابزارهای جدید نباید از آنها استفاده کنید:

  • اگر می‌خواهید بهترین عملکرد را داشته باشید، از /emscripten-wasm32 (با جایگزینی برای /emscripten-asmjs) به جای /bin استفاده کنید. ما تا نسخه 0.6.1 فقط فایل‌های باینری asm.js را ارائه می‌دادیم. با شروع 0.6.2، ما به WebAssembly builds به عملکرد بسیار بهتر روی آوردیم. ما نسخه‌های قدیمی تر را برای wasm بازسازی کرده‌ایم اما فایل‌های اصلی asm.js در /bin باقی می‌مانند. موارد جدید باید در یک فهرست جداگانه قرار داده شوند تا از تصادم نامی جلوگیری شود.
  • اگر می‌خواهید مطمئن شوید که در حال بارگیری wasm یا باینری asm.js هستید، از /emscripten-asmjs و /emscripten-wasm32 به جای /bin و /wasm استفاده کنید.
  • به جای list.js و list.txt از list.json استفاده کنید. فرمت لیست JSON شامل تمام اطلاعات قدیمی و بیشتر است.
  • به جای https://binaries.soliditylang.org از https://solc-bin.ethereum.org/استفاده کنید. برای ساده نگه داشتن مسائل، ما تقریباً همه چیز مربوط به کامپایلر را تحت دامنه جدید  soliditylang.org  منتقل کردیم و این امر در مورد solc-bin نیز صدق می‌کند. با اینکه دامنه جدید توصیه می‌شود، اما دامنه قبلی هنوز کاملاً پشتیبانی می‌شود و تضمین می‌شود که به همان مکان اشاره می‌کند.

هشدار

فایل‌های باینری نیز در 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++ زیر و حداقل نسخه‌های آنها می‌توانند پایگاه کد سالیدیتی را ایجاد کنند:

  • GCC ، نسخه +8
  • Clang ، نسخه +7
  • MSVC ، نسخه +2019

پیش نیازها – مک‌او اس

برای نسخه‌های مک‌او اس، مطمئن شوید که آخرین نسخه 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 نصب شود، آورده شده‌است:

  • ویژگی های اصلی ++Visual Studio C
  • مجموعه ابزارهای VC 2019 v141 toolset (x86,x64)
  • CRT SDK ویندوز یونیورسال
  • SDK ویندوز 8.1
  • پشتیبانی از C ++/CLI

ما یک اسکریپت کمکی داریم که می توانید از آن برای نصب تمام وابستگی های خارجی مورد نیاز استفاده کنید:

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 در دسترس هستند، cmake .. -LH را اجرا کنید.

حل کننده‌های SMT

سالیدیتی را می‌توان در کنار حل کننده‌های 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

رشته نسخه با جزئیات

رشته نسخه سالیدیتی شامل چهار قسمت است:

  • شماره نسخه
  • برچسب پیش از انتشار، معمولاً با  develop.YYYY.MM.DD یا  nightly.YYYY.MM.DD تنظیم می‌شود.
  • کامیت در قالب  commit.GITHASH
  • پلتفرم، که دارای تعداد دلخواه موارد است، حاوی جزئیات مربوط به پلتفرم و کامپایلر

اگر تغییرات محلی وجود داشته باشد، کامیت‌ها با 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

مثال:

  1. نسخه 4.0 ساخته شده است.

  2. نسخه شبانه از این پس نسخه 4.1 دارد.

  3. تغییرات بدون تفکیک (breaking) ارائه می شوند – > بدون تغییر در نسخه.

  4. یک تغییر تفکیک معرفی می‌شود – > نسخه به 5.0 افزایش می یابد.

  5. نسخه 0.5.0 ساخته شده است.

این رفتار با نسخه پراگما به خوبی کار می‌کند.

دسته بندی هاآموزش برنامه نویسی

FacebookTwitterPinterestWhatsappTelegramEmail

مطالب مرتبط

ارسال نظر غیر فعال شده