Hello, this is eosBLACK team!
As the v1.2.0 was released on August 15th, 2018, it was reported that the contract build script ‘eosiocpp’ from EOSIO v1.3.0 will no longer be used. Additionally, on September 20th, with the release of EOSIO v1.3.0, EOSIO officially introduced EOSIO.CDT, which makes contract creation easy. In this post, we will take a look at what has been updated with this toolkit.
Reference : https://github.com/EOSIO/eosio.cdt
For your information, eosiocpp will remain available for the time being, but as future upgrades will take place in EOSIO.CDT, it is advised that you export your development environment well in advance.
This article is based on eosio.cdt v1.2.0 after installing Ubuntu 16.04 under the wsl of Windows 10.
Installation
●Source replication
First, replicate the source. Of the tags, v1.2.0 has been checked out.
●Build & installation method
The core symbol has been assigned as ‘EOS’.
The installation path is ‘/usr/local/eosio.cdt/’. Related commands are symbolically linked to ‘/usr/local/bin’. The major difference is that eosio-cpp is used instead of eosiocpp. Let us illustrate the details of the difference with actual examples.
Let’s take a look at a simple example.
Let’s try creating the simple contract example as follows:
mytest.hpp
mytest.cpp
We will start by building with eosiocpp to compare this with the previous method.
The size displayed for mytest.wasm is 3,059 bytes. ABI is displayed properly as well. We will try eosio-cpp for today’s session.
The size displayed for mytest.wasm is 2,392 bytes. Although we will explain it later, there is a noticeable diet in the compilation results even when the same -03 option is passed. In EOSIO, the size of a contract is directly linked to the cost, so it can be said that the small size is an adequate reason to move it. See? Nothing is displayed here. The problem is the ABI file. Yes, it is empty. This is because eosio-abigen fails to recognize the ‘footnote’ in the old format. Let’s start by creating this ABI in a legitimate form.
Let’s take a closer look.
●ABI creation
With eosiocpp in the previous method, the ABI information can be displayed by annotating the action or table as follows:
For modified eosio-cpp, use the C++11 attribute to describe the ABI to be displayed.
Or,
Modify mytest.hpp, which was pointed out as a problem earlier, according to the changed rule as follows.
Rebuild it, and you can see the correctly displayed ABI.
●ABI creation: Advanced
‘~/eosio.cdt/example/abigen_test/test.cpp’ contains the examples of how to create an ABI.
I will organize them by case after compiling.
First is the action definition of the structure.
The resulting output is as follows:
The following is an example of indicating the name of an inherited structure. The action / table type can use 32 strings ('.12345abcdefghijklmnopqrstuvwxyz') and is encoded as a 64-bit integer. Up to 13 characters can be created. Up to 12 digits can be used for 32 strings. The 13th character can only be written as '1-5' and 'a-j'. These limitations cause frustration for coding, but can be addressed by naming the internal code and the external interface differently. If the structure declaration and the display name of the ABI are different, they can be indicated as follows:
The output result is as follows:
Now let’s take a look at how to define the actions of a function. This is an example of indicating the name of an action.
The output result is as follows:
This is an example in which the defined name is used as is. Also take a note of the fact that the passed factor value is the test_c type defined earlier.
Last but not least is the definition of a table. This time, let me show an example where two different multi-index tables are defined with the same structure.
The resulting output is as follows:
This is an example of indicating the name of a table.
The resulting output is as follows:
Exploring behavior
The eosio.cdt environment is, in short, an interpreter for the clang toolchain targeting wasm32. You can safely assume that eosiocpp, which was provided as a shell script, is changed to C. It is not easy to transfer compiled executables such as eosio-cpp, eosio-ld, etc. to another computer, since related directories, especially the ‘include’ path of Boost, belong to the current system during the build process. This explains why it is quite meaningful to understand what parameters eosio-cpp passes to the actual clang toolchain.
The source of eosio-cpp can be found in ‘~/eosio.cdt/build/EosioClang-prefix/src/EosioClang-build/eosio-cpp.cpp’.
In other words, the ‘~/eosio.cdt/eosio_llvm/tools/clang/tools/extra/eosio_c_tool/eosio-cpp.cpp.in’ file has been converted to the current local environment during the building process. The same applies to the rest of the sources including eosio-ld.cpp, eosio-abigen.cpp, and so on.
We call **clang** for the compilation of the contract sources, eosio-ld for the link, and eosio-abigen for the abi creation. To see how the command lines are passed at each step, there are instr, linkstr, genstr, and others of eosio-cpp and eosio-ld displayed on the console.
After rebuilding, I compiled mytest.cpp.
As mentioned earlier, “-03” is passed as the optimization option.
Take a look at the eosio-abigen.cpp source, and you will notice that most of the options passed are already recorded in the source code itself. Thus, to create an ABI just like the old “eosiocpp -g”, you can use a simple command line as follows:
One strange thing is that if the eosio-abigen path is already in your PATH, omitting the execution path will produce the following error:
The parameter passing part is still being edited, but it can be expected to be fixed soon. One of the eosio-cpp options that is noticeable is -I, which serves to specify the path when using an external header file. See below for its usage.
This option is best conveyed as the -I factor when calling clang++, but
it is omitted with abigen.
In the eosio-xx command, a double en-dash “ — “ is an option to pass commands directly to the toolchain. Thus, I wondered if it would work if I try it in the following way:
Although it is conveyed correctly in the compilation
at the abigen stage, it gets stuck in the front area all of a sudden.
When using external headers, therefore, you should add additional options with a double en-dash while directly calling eosio-abigen as described above.
v1.2.1 was released just after this post was written. The issue where the -I parameter was not conveyed is said to have been fixed.
https://github.com/EOSIO/eosio.cdt/releases/tag/v1.2.1
Wrap-up
EOSIO is still at early stage. The addition of a dash to eosiocpp makes the process of changing into eosio-cpp straightforward and bold. I hope that this post can serve as a small guide for your pleasant development processes in the midst of the ever-changing eosio.
Thank you.
eosBLACK Team
eosBLACK Contact
eosBLACK Homepage : http://eosblack.io
eosBLACK Koreos : http://koreos.io/eosBLACK
eosBLACK Medium : https://medium.com/@eosblack
eosBLACK steemit : https://steemit.com/@eosblack
eosBLACK Facebook : https://www.facebook.com/eosBLACKTeam
eosBLACK twitter : https://twitter.com/EOSBLACK_IO
eosBLACK Telegram(Korean) : https://t.me/eosBLACK_Korea
eosBLACK Telegram(English) : https://t.me/eosBLACK_English
White Paper (Korean) : http://bitly.kr/nap2
White Paper (English) : http://bitly.kr/MOsA!