running.rst 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239
  1. Using Solang on the command line
  2. ================================
  3. The Solang compiler is run on the command line. The solidity source file
  4. names are provided as command line arguments; the output is an optimized
  5. WebAssembly or Solana SBF file which is ready for deployment on a chain, and an metadata
  6. file (also known as the abi).
  7. The following targets are supported right now:
  8. `Solana <https://www.solana.com/>`_ and
  9. `Parity Substrate <https://substrate.io/>`_.
  10. Solang supports auto-completion for multiple shells. Use ``solang shell-complete --help`` to
  11. learn whether your favorite shell is supported. If so, evaluate the output of
  12. ``solang shell-complete <SHELL>`` in order to activate it. Example installation with ``bash``:
  13. .. code-block:: bash
  14. echo 'source <(solang shell-complete bash)' >> ~/.bashrc
  15. Compiler Usage
  16. ______________
  17. solang compile [OPTIONS]... [SOLIDITY SOURCE FILE]...
  18. This means that the command line is ``solang compile`` followed by any options described below,
  19. followed by one or more solidity source filenames.
  20. Options:
  21. -v, \-\-verbose
  22. Make the output more verbose. The compiler tell you what contracts have been
  23. found in the source, and what files are generated. Without this option Solang
  24. will be silent if there are no errors or warnings.
  25. \-\-target *target*
  26. This takes one argument, which can either be ``solana`` or ``substrate``. The target
  27. must be specified.
  28. \-\-address\-length *length-in-bytes*
  29. Change the default address length on Substrate. By default, Substate uses an address type of 32 bytes. This option
  30. is ignored for any other target.
  31. \-\-value\-length *length-in-bytes*
  32. Change the default value length on Substrate. By default, Substate uses an value type of 16 bytes. This option
  33. is ignored for any other target.
  34. -o, \-\-output *directory*
  35. Sets the directory where the output should be saved. This defaults to the current working directory if not set.
  36. \-\-output\-meta *directory*
  37. Sets the directory where metadata should be saved. For Solana, the metadata is the Anchor IDL file,
  38. and, for Substrate, the .contract file. If this option is not set, the directory specified by ``--output``
  39. is used, and if that is not set either, the current working directory is used.
  40. \-\-contract *contract-name* [, *contract-name*]...
  41. Only compile the code for the specified contracts. If any those contracts cannot be found, produce an error.
  42. -O *optimization level*
  43. This takes one argument, which can either be ``none``, ``less``, ``default``,
  44. or ``aggressive``. These correspond to llvm optimization levels.
  45. \-\-importpath *directory*
  46. When resolving ``import`` directives, search this directory. By default ``import``
  47. will only search the current working directory. This option can be specified multiple times
  48. and the directories will be searched in the order specified.
  49. \-\-importmap *map=directory*
  50. When resolving ``import`` directives, if the first part of the path matches *map*,
  51. search the directory provided for the file. This option can be specified multiple times
  52. with different values for map.
  53. \-\-help, -h
  54. This displays a short description of all the options
  55. \-\-standard-json
  56. This option causes Solang to emulate the behaviour of Solidity
  57. `standard json output <https://solidity.readthedocs.io/en/v0.5.13/using-the-compiler.html#output-description>`_. No output files are written, all the
  58. output will be in json on stdout.
  59. \-\-emit *phase*
  60. This option is can be used for debugging Solang itself. This is used to
  61. output early phases of compilation.
  62. Phase:
  63. ast-dot
  64. Output Abstract Syntax Tree as a graphviz dot file. This can be viewed with xdot
  65. or any other tool that can visualize graphviz dot files.
  66. cfg
  67. Output control flow graph.
  68. llvm-ir
  69. Output llvm IR as text.
  70. llvm-bc
  71. Output llvm bitcode as binary file.
  72. asm
  73. Output assembly text file.
  74. object
  75. Output wasm object file; this is the contract before final linking.
  76. \-\-no\-constant\-folding
  77. Disable the :ref:`constant-folding` codegen optimization
  78. \-\-no\-strength\-reduce
  79. Disable the :ref:`strength-reduce` codegen optimization
  80. \-\-no\-dead\-storage
  81. Disable the :ref:`dead-storage` optimization
  82. \-\-no\-vector\-to\-slice
  83. Disable the :ref:`vector-to-slice` optimization
  84. \-\-no\-cse
  85. Disable the :ref:`common-subexpression-elimination` optimization
  86. \-\-no\-log\-api\-return\-codes
  87. Disable the :ref:`no-log-api-return-codes` debugging feature
  88. \-\-no\-log\-runtime\-errors
  89. Disable the :ref:`no-log-runtime-errors` debugging feature
  90. \-\-no\-prints
  91. Disable the :ref:`no-print` debugging feature
  92. \-\-release
  93. Disable all debugging features for :ref:`release`
  94. .. warning::
  95. If multiple Solidity source files define the same contract name, you will get a single
  96. compiled contract file for this contract name. As a result, you will only have a single
  97. contract with the duplicate name without knowing from which Solidity file it originated.
  98. Solang will not give a warning about this problem.
  99. Generating Documentation Usage
  100. ______________________________
  101. Generate documentation for the given Solidity files as a single html page. This uses the
  102. doccomment tags. The result is saved in ``soldoc.html``. See :ref:`tags` for
  103. further information.
  104. solang doc [OPTIONS]... [SOLIDITY SOURCE FILE]...
  105. This means that the command line is ``solang doc`` followed by any options described below,
  106. followed by one or more solidity source filenames.
  107. Options:
  108. \-\-target *target*
  109. This takes one argument, which can either be ``solana`` or ``substrate``. The target
  110. must be specified.
  111. \-\-address\-length *length-in-bytes*
  112. Change the default address length on Substrate. By default, Substate uses an address type of 32 bytes. This option
  113. is ignored for any other target.
  114. \-\-value\-length *length-in-bytes*
  115. Change the default value length on Substrate. By default, Substate uses an value type of 16 bytes. This option
  116. is ignored for any other target.
  117. \-\-importpath *directory*
  118. When resolving ``import`` directives, search this directory. By default ``import``
  119. will only search the current working directory. This option can be specified multiple times
  120. and the directories will be searched in the order specified.
  121. \-\-importmap *map=directory*
  122. When resolving ``import`` directives, if the first part of the path matches *map*,
  123. search the directory provided for the file. This option can be specified multiple times
  124. with different values for map.
  125. \-\-help, -h
  126. This displays a short description of all the options
  127. .. _idl_command:
  128. Generate Solidity interface from IDL
  129. ____________________________________
  130. This command converts Anchor IDL into Solidity import files, so they can be used to call
  131. Anchor Programs from Solidity.
  132. solang idl [--output DIR] [IDLFILE]...
  133. For each idl file provided, a Solidity file is written. See :ref:`call_anchor`
  134. for an example of how to use this.
  135. .. note::
  136. There is only supported on Solana.
  137. Running Solang using a container
  138. ________________________________
  139. First pull the last Solang container from
  140. `solang containers <https://github.com/hyperledger/solang/pkgs/container/solang>`_:
  141. .. code-block:: bash
  142. docker image pull ghcr.io/hyperledger/solang
  143. And if you are using podman:
  144. .. code-block:: bash
  145. podman image pull ghcr.io/hyperledger/solang
  146. Now you can run Solang like so:
  147. .. code-block:: bash
  148. docker run --rm -it ghcr.io/hyperledger/solang --version
  149. Or podman:
  150. .. code-block:: bash
  151. podman container run --rm -it ghcr.io/hyperledger/solang --version
  152. If you want to compile some Solidity files, the source files need to be
  153. available inside the container. You can do this via the ``-v`` docker command line.
  154. In this example ``/local/path`` should be replaced with the absolute path
  155. to your solidity files:
  156. .. code-block:: bash
  157. docker run --rm -it -v /local/path:/sources ghcr.io/hyperledger/solang compile -o /sources /sources/flipper.sol
  158. On Windows, you need to specify absolute paths:
  159. .. code-block:: text
  160. docker run --rm -it -v C:\Users\User:/sources ghcr.io/hyperledger/solang compile -o /sources /sources/flipper.sol