diff --git a/CMakeLists.txt b/CMakeLists.txt index 8b562ffd22..925dcf8e3c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -75,9 +75,9 @@ install(FILES ${CMAKE_BINARY_DIR}/scripts/ricardeos.py DESTINATION ${CDT_INSTALL # section for package construction set(VENDOR "EOSNetworkFoundation") set(PROJECT_NAME "cdt") -set(DESC "Toolchain and supporting tools for the Mandel platform") -set(URL "https://github.com/eosnetworkfoundation/mandel.cdt") -set(EMAIL "support@block.one") +set(DESC "Toolchain and supporting tools to facilitate C/C++ development of contracts for Antelope blockchains") +set(URL "https://github.com/AntelopeIO/cdt") +set(EMAIL "support@eosnetwork.com") configure_file(${CMAKE_SOURCE_DIR}/scripts/generate_package.sh.in ${CMAKE_BINARY_DIR}/packages/generate_package.sh @ONLY) configure_file(${CMAKE_SOURCE_DIR}/scripts/generate_deb.sh ${CMAKE_BINARY_DIR}/packages/generate_deb.sh COPYONLY) configure_file(${CMAKE_SOURCE_DIR}/scripts/generate_bottle.sh ${CMAKE_BINARY_DIR}/packages/generate_bottle.sh COPYONLY) diff --git a/LICENSE b/LICENSE index ea360c19f2..86f6942434 100644 --- a/LICENSE +++ b/LICENSE @@ -1,4 +1,4 @@ -eosnetworkfoundation/mandel.cdt +AntelopeIO/cdt Copyright (c) 2021-2022 EOS Network Foundation (ENF) and its contributors. All rights reserved. This ENF software is based upon: diff --git a/README.md b/README.md index 00ee5bfa10..6dbcb19f67 100644 --- a/README.md +++ b/README.md @@ -1,23 +1,39 @@ # CDT (Contract Development Toolkit) -## Version : 3.0.0 -CDT is a toolchain for WebAssembly (WASM) and a set of tools to facilitate smart contract development for the Mandel platform. In addition to being a general purpose WebAssembly toolchain, [Mandel](https://github.com/eosnetworkfoundation/mandel) specific optimizations are available to support building smart contracts. This new toolchain is built around [Clang 9](https://github.com/eosnetworkfoundation/cdt-llvm), which means that CDT has the most currently available optimizations and analyses from LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available. +Contract Development Toolkit (CDT) is a C/C++ toolchain targeting WebAssembly (WASM) and a set of tools to facilitate development of smart contracts written in C/C++ that are meant to be deployed to an [Antelope](https://github.com/AntelopeIO/) blockchain. + +In addition to being a general purpose WebAssembly toolchain, specific features and optimizations are available to support building Antelope-based smart contracts. This new toolchain is built around [Clang 9](https://github.com/AntelopeIO/cdt-llvm), which means that CDT inherits the optimizations and analyses from that version of LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available. + +## Repo organization + +The `main` branch is the development branch: do not use this for production. Refer to the [release page](https://github.com/AntelopeIO/cdt/releases) for current information on releases, pre-releases, and obsolete releases as well as the corresponding tags for those releases. +## Binary packages + +CDT currently supports Linux x86_64 Debian packages. Visit the [release page](https://github.com/AntelopeIO/cdt/releases) to download the package for the appropriate version of CDT. This is the fastest way to get started with the software. +### Debian package install + +The latest version of CDT is 3.0. Download the appropriate version of the Debian package and then install as follows: -## Binary Releases -CDT currently supports Linux x86_64 Debian packages. -### Debian Package Install ```sh -wget https://github.com/eosnetworkfoundation/mandel.cdt/releases/download/v3.0.0-rc1/cdt_3.0.0-rc1_amd64.deb +wget https://github.com/AntelopeIO/cdt/releases/download/v3.0.0-rc1/cdt_3.0.0-rc1_amd64.deb sudo apt install ./cdt_3.0.0-rc1_amd64.deb ``` -### Debian Package Uninstall +### Debian package uninstall + +To remove CDT that was installed using a Debian package, simply execute the following command: + ```sh sudo apt remove cdt ``` -## Building +## Building from source + +Recent Ubuntu LTS releases are the only Linux distributions that we fully support. Other Linux distros and other POSIX operating systems (such as macOS) are tended to on a best-effort basis and may not be full featured. + +The instructions below assume that you are building on Ubuntu 20.04. + +### Install dependencies -### Ubuntu 20.04 dependencies ```sh apt-get update && apt-get install \ build-essential \ @@ -30,61 +46,114 @@ apt-get update && apt-get install \ python3-pip \ time ``` + ```sh python3 -m pip install pygments ``` -If issues persist with ccache +### Allowing integration tests to build + +Integration tests require access to a build of [Leap](https://github.com/AntelopeIO/leap), a C++ implementation of the Antelope protocol. Simply installing Leap from a binary package will not be sufficient. + +If you do not wish to build Leap, you can continue with building CDT but without building the integration tests. Otherwise, follow the instructions below before running `cmake`. + +First, ensure that Leap has been built from source (see Leap's [README](https://github.com/AntelopeIO/leap#building-from-source) for details) and identify the build path, e.g. `/path/to/leap/build/`. + +Then, execute the following command in the same terminal session that you will use to build CDT: + ```sh -export CCACHE_DISABLE=1 +export leap_DIR=/path/to/leap/build/lib/cmake/leap ``` -### Building Integration Tests - -Integration tests require access to a mandel build. Instructions below provide additional steps for using a mandel built from source. For development purposes it is generally advised to use mandel built from source. +Now you can continue with the steps to build CDT as described. When you run `cmake` make sure that it does not report `leap package not found`. If it does, this means CDT was not able to find a build of Leap at the specified path in `leap_DIR` and will therefore continue without building the integration tests. -#### For building integration tests with mandel built from source +### ccache -Set an environment variable to tell CDT where to find the Mandel build directory: +If issues persist with ccache when building CDT, you can disable ccache: ```sh -export eosio_DIR=/path/to/mandel/build/lib/cmake/eosio +export CCACHE_DISABLE=1 ``` -### Guided Installation or Building from Scratch +### Build CDT + +**A Warning On Parallel Compilation Jobs (`-j` flag)**: When building C/C++ software often the build is performed in parallel via a command such as `make -j $(nproc)` which uses the number of CPU cores as the number of compilation jobs to perform simultaneously. However, be aware that some compilation units (.cpp files) in CDT are extremely complex and can consume a large amount of memory to compile. If you are running into issues due to amount of memory available on your build host, you may need to reduce the level of parallelization used for the build. For example, instead of `make -j $(nproc)` you can try `make -j2`. Failures due to memory exhaustion will typically but not always manifest as compiler crashes. + ```sh -git clone --recursive https://github.com/eosnetworkfoundation/mandel.cdt -cd mandel.cdt +git clone --recursive https://github.com/AntelopeIO/cdt +cd cdt mkdir build cd build cmake .. -make -j8 +make -j $(nproc) ``` -From here onward you can build your contracts code by simply exporting the `build` directory to your path, so you don't have to install globally (makes things cleaner). -Or you can install globally by running this command: +The binaries will be located at in the `build/bin` directory. You can export the path to the directory to your `PATH` environment variable which allows you to conveniently use them to compile contracts without installing CDT globally. Alternatively, you can use CMake toolchain file located in `build/lib/cmake/CDTWasmToolchain.cmake` to compile the contracts in your CMake project, which also allows you to avoid installing CDT globally. -```sh -sudo make install -``` +If you would prefer to install CDT globally, see the section [Install CDT](#install-cdt) below. -### Running Tests +### Run tests + +#### Run unit tests -#### Unit Tests ```sh cd build ctest ``` -#### Running Integration Tests (if built) +#### Run integration tests (if built) + ```sh cd build/tests/integration ctest ``` -### Uninstall after manual installation +### Install CDT + +Installing CDT globally on your system will install the following tools in a location accessible to your `PATH`: + +* cdt-abidiff +* cdt-ar +* cdt-cc +* cdt-cpp +* cdt-init +* cdt-ld +* cdt-nm +* cdt-objcopy +* cdt-objdump +* cdt-ranlib +* cdt-readelf +* cdt-strip +* eosio-pp +* eosio-wasm2wast +* eosio-wast2wasm + +It will also install CMake files for CDT accessible within a `cmake/cdt` directory located within your system's `lib` directory. +#### Manual installation + +One option for installing CDT globally is via `make install`. From within the `build` directory, run the following command: + +``` +sudo make install +``` + +#### Package installation + +A better option for installing CDT globally is to generate a package and then install the package. This makes uninstalling CDT much easier. + +From within the `build` directory, run the following commands to generate a Debian package: + +```sh +cd packages +bash ./generate_package.sh deb ubuntu-20.04 amd64 +sudo apt install ./cdt_*_amd64.deb +``` + +### Uninstall CDT + +#### Uninstall CDT after manual installation with make ```sh sudo rm -fr /usr/local/cdt @@ -93,20 +162,12 @@ sudo rm /usr/local/bin/eosio-* sudo rm /usr/local/bin/cdt-* ``` -## Installed Tools ---- -* cdt-cpp -* cdt-cc -* cdt-ld -* cdt-init -* cdt-abidiff -* cdt-wasm2wast -* cdt-wast2wasm -* cdt-ranlib -* cdt-ar -* cdt-objdump -* cdt-readelf +#### Uninstall CDT that was installed using a Debian package + +```sh +sudo apt remove cdt +``` ## License -[MIT](./LICENSE) \ No newline at end of file +[MIT](./LICENSE) diff --git a/docs.json b/docs.json index f9fb477152..70b7a2c01f 100644 --- a/docs.json +++ b/docs.json @@ -1,5 +1,5 @@ { - "name": "eosio.cdt", + "name": "cdt", "generators": [ { "name": "collate_markdown", diff --git a/docs/02_installation/index.md b/docs/02_installation/index.md index 0f1c35f5df..1818089066 100644 --- a/docs/02_installation/index.md +++ b/docs/02_installation/index.md @@ -1,62 +1,5 @@ --- -content_title: Binary Releases +content_title: Installation --- -CDT currently supports Linux x86_64 Debian packages. - -## Debian Package Install - -```sh -wget https://github.com/eoscdt/releases/download/v3.0.0/cdt_3.0.0_amd64.deb -sudo apt install ./cdt_3.0.0_amd64.deb -``` - -## Debian Package Uninstall - -```sh -sudo apt remove cdt -``` - -# Guided Installation or Building from Scratch - -```sh -git clone --recursive https://github.com/eosnetworkfoundation/mandel.cdt -cd eosio.cdt -mkdir build -cd build -cmake .. -make -j8 -``` - -From here onward you can build your contracts code by simply exporting the `build` directory to your path, so you don't have to install globally (makes things cleaner). -Or you can install globally by running this command - -```sh -sudo make install -``` - -## Uninstall after manual installation - -```sh -sudo rm -fr /usr/local/cdt -sudo rm -fr /usr/local/lib/cmake/cdt -sudo rm /usr/local/bin/eosio-* -sudo rm /usr/local/bin/cdt-* -``` - -# Installed Tools - -* cdt-cpp -* cdt-cc -* cdt-ld -* cdt-init -* cdt-abidiff -* cdt-wasm2wast -* cdt-wast2wasm -* cdt-ranlib -* cdt-ar -* cdt-objdump -* cdt-readelf - -License -[MIT](../LICENSE) +See README of https://github.com/AntelopeIO/cdt for instructions on how to build and install CDT. diff --git a/docs/03_command-reference/cdt-abigen.md b/docs/03_command-reference/cdt-abigen.md deleted file mode 100644 index 4559c7f1eb..0000000000 --- a/docs/03_command-reference/cdt-abigen.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -content_title: cdt-abigen tool ---- - -## This tool is deprecated, use `cdt-cpp` for generation of your ABIs - -To generate an ABI with ```cdt-abigen```, only requires that you give the main '.cpp' file to compile and the output filename `--output` and generating against the contract name `--contract`. - -Example: -```bash -$ cdt-abigen hello.cpp --contract=hello --output=hello.abi -``` - -This will generate one file: -* The generated ABI file (hello.abi) -``` -USAGE: cdt-abigen [options] [... ] - -OPTIONS: - -Generic Options: - - -help - Display available options (-help-hidden for more) - -help-list - Display list of available options (-help-list-hidden for more) - -version - Display the version of this program - -cdt-abigen: -generates an ABI from C++ project input - - -extra-arg= - Additional argument to append to the compiler command line - -extra-arg-before= - Additional argument to prepend to the compiler command line - -output= - Set the output filename and fullpath - -p= - Build path -``` diff --git a/docs/04_upgrading/eosio.cdt-to-cdt.md b/docs/04_upgrading/eosio.cdt-to-cdt.md new file mode 100644 index 0000000000..d2e1de5731 --- /dev/null +++ b/docs/04_upgrading/eosio.cdt-to-cdt.md @@ -0,0 +1,11 @@ +--- +content_title: EOSIO.CDT To CDT +--- + +For this release all of the naming of namespaces and file paths will remain as `eosio`, so there is no need to migrate away from that with this release. + +But there are a few differences. + +1. The tool names have change prefix. I.e. tools like `eosio-cpp` are now `cdt-cpp`. +2. The CMake toolchain file has changed its name from `EosioWasmToolchain.cmake` to `CDTWasmToolchain.cmake`. +3. The library path for the CMake package has changed from `/usr/local/lib/cmake/eosio.cdt` to `/usr/local/lib/cmake/cdt` (or alternatively from `/usr/lib/cmake/eosio.cdt` to `/usr/lib/cmake/cdt` if installing from the Debian package). Additionally, the name to use with CMake `find_package` has similarly changed: use `find_package(cdt)` now instead of `find_package(eosio.cdt)`. diff --git a/docs/04_upgrading/eosio.cdt-to-mandel.cdt.md b/docs/04_upgrading/eosio.cdt-to-mandel.cdt.md deleted file mode 100644 index d5aab3e887..0000000000 --- a/docs/04_upgrading/eosio.cdt-to-mandel.cdt.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -content_title: EOSIO.CDT To Mandel.CDT ---- - -For this release all of the naming of namespaces and file paths will remain as `eosio`, so no need to migrate away from that with this release. - -But there are a few differences. - -1. The tool names have change prefix. I.e. tools like `eosio-cpp` are now `cdt-cpp`. -2. The cmake toolchain file has changed its name from `EosioWasmToolchain.cmake` to `CDTWasmToolchain.cmake`. -3. The library path for the cmake package and package name have changed. `/usr/local/lib/cmake/eosio.cdt` to `/usr/local/lib/cmake/cdt` and in cmake `find_package(eosio.cdt)` to `find_package(cdt)`. \ No newline at end of file diff --git a/docs/05_features/10_return_values_from_actions.md b/docs/05_features/10_return_values_from_actions.md index 48404e367c..b990628937 100644 --- a/docs/05_features/10_return_values_from_actions.md +++ b/docs/05_features/10_return_values_from_actions.md @@ -4,7 +4,7 @@ content_title: Return Values From Actions ## Overview -`Mandel` version 3.1 enables you to return any value from any action. This new feature facilitates easier smart contract implementation debugging, and better messaging between a smart contract and its clients. From now on the clients of a smart contract are able to use the value returned by an action, no more string parsing on the client side and no more print statements in the smart contract implementation. +An Antelope blockchain with the `ACTION_RETURN_VALUE` protocol feature activated enables you to return any value from any action. This new feature facilitates easier smart contract implementation debugging, and better messaging between a smart contract and its clients. From now on the clients of a smart contract are able to use the value returned by an action, no more string parsing on the client side and no more print statements in the smart contract implementation. ## Concept @@ -14,7 +14,7 @@ When you implement an action within a smart contract use the `return` statement The following list provides important details for when you return a value from an action: -* As mentioned above, the `EOSIO` framework does all the heavy lifting for the return value to convey it to the client. The `EOSIO` framework defines and uses a new intrinsic, namely `set_action_return_value`. To learn more about `EOSIO` returned values functionality, refer to its documentation and [implementation](https://github.com/eosnetworkfoundation/mandel.cdt/blob/develop/libraries/native/intrinsics.cpp#L295). +* As mentioned above, the `EOSIO` framework does all the heavy lifting for the return value to convey it to the client. The `EOSIO` framework defines and uses a new intrinsic, namely `set_action_return_value`. To learn more about `EOSIO` returned values functionality, refer to its documentation and [implementation](https://github.com/AntelopeIO/cdt/blob/develop/libraries/native/intrinsics.cpp#L295). * The CPU time and memory limit of your contract (maximum size of wasm), not RAM or NET, defines the limits of the returned value.. * The action receipt includes a hash of the serialized returned value. * The action trace includes the serialized returned value. @@ -27,5 +27,5 @@ The following list provides important details for when you return a value from a For a full working example of a smart contract action which returns a value, refer to the following resources: -* The [`hello`](https://github.com/eosnetworkfoundation/mandel.cdt/blob/develop/examples/hello/src/hello.cpp#L14) smart contract example, see action `hello::checkwithrv`. +* The [`hello`](https://github.com/AntelopeIO/cdt/blob/develop/examples/hello/src/hello.cpp#L14) smart contract example, see action `hello::checkwithrv`. * The [How-to return values from actions](../06_how-to-guides/60_how-to-return-values-from-actions.md). diff --git a/docs/05_features/30_binary-extension.md b/docs/05_features/30_binary-extension.md index d92e114d0e..612a22a10a 100644 --- a/docs/05_features/30_binary-extension.md +++ b/docs/05_features/30_binary-extension.md @@ -4,7 +4,7 @@ content_title: The eosio::binary_extension Type Let's fully explain what the `eosio::binary_extension` type is, what it does, and why we need it for contract upgrades in certain situations. -You can find the implementation of `eosio::binary_extension` in the `eosio.cdt` repository in file: `eosio.cdt/libraries/eosiolib/core/eosio/binary_extension.hpp`. +You can find the implementation of `eosio::binary_extension` within the CDT repository in the file: `libraries/eosiolib/core/eosio/binary_extension.hpp`. Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in an `eosio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration. @@ -366,7 +366,7 @@ Find below their corresponding sections in the `.abi` files: Now, let's start up a blockchain instance, compile this smart contract, and test it out. ``` -~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm +~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm ``` ``` @@ -511,7 +511,7 @@ struct [[eosio::table]] structure { Next, let's upgrade the contract and try to read from our table and write to our table the original way: ``` -~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm +~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm ``` ``` diff --git a/docs/05_features/40_native-tester-compilation.md b/docs/05_features/40_native-tester-compilation.md index 0614733545..216b8e2e50 100644 --- a/docs/05_features/40_native-tester-compilation.md +++ b/docs/05_features/40_native-tester-compilation.md @@ -2,7 +2,7 @@ content_title: Native Tester And Compilation --- -As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. [`cdt-cc`](../03_command-reference/cdt-cc.md), [`cdt-cpp`](../03_command-reference/cdt-cpp.md) and [`cdt-ld`](../03_command-reference/cdt-ld.md) now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development \(note the default implementations of a lot of the mandel `intrinsics` are currently asserts that state they are unavailable, these are user definable.\) +As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. [`cdt-cc`](../03_command-reference/cdt-cc.md), [`cdt-cpp`](../03_command-reference/cdt-cpp.md) and [`cdt-ld`](../03_command-reference/cdt-ld.md) now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development (note the default implementations of a lot of the Antelope intrinsics (aka host functions) are currently asserts that state they are unavailable, these are user definable.) ## Getting Started Once you have your smart contract written then a test source file can be written. @@ -91,10 +91,10 @@ int main(int argc, char** argv) { } ``` -Every `intrinsic` that is defined for eosio (prints, require_auth, etc.) is re-definable given the `intrinsics::set_intrinsics()` functions. These take a lambda whose arguments and return type should match that of the intrinsic you are trying to define. This gives the contract writer the flexibility to modify behavior to suit the unit test being written. A sister function `intrinsics::get_intrinsics()` will return the function object that currently defines the behavior for said intrinsic. This pattern can be used to mock functionality and allow for easier testing of smart contracts. For more information see, either the [tests](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/tests/) directory or [hello_test.cpp](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/tests/hello_test.cpp) for working examples. +Every `intrinsic` that is defined for eosio (prints, require_auth, etc.) is re-definable given the `intrinsics::set_intrinsics()` functions. These take a lambda whose arguments and return type should match that of the intrinsic you are trying to define. This gives the contract writer the flexibility to modify behavior to suit the unit test being written. A sister function `intrinsics::get_intrinsics()` will return the function object that currently defines the behavior for said intrinsic. This pattern can be used to mock functionality and allow for easier testing of smart contracts. For more information see, either the [tests](https://github.com/AntelopeIO/cdt/tree/main/examples/hello/tests/) directory or [hello_test.cpp](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/tests/hello_test.cpp) for working examples. ## Compiling Native Code -- Raw `eosio-cpp` to compile the test or program the only addition needed to the command line is to add the flag `-fnative` this will then generate native code instead of `wasm` code. +- Raw `cdt-cpp` to compile the test or program the only addition needed to the command line is to add the flag `-fnative` this will then generate native code instead of `wasm` code. - Via CMake - `add_native_library` and `add_native_executable` CMake macros have been added (these are a drop in replacement for add_library and add_executable). diff --git a/docs/06_how-to-guides/10_compile/02_how-to-configure-cmake.md b/docs/06_how-to-guides/10_compile/02_how-to-configure-cmake.md index ef6343c16c..c62cd2a051 100644 --- a/docs/06_how-to-guides/10_compile/02_how-to-configure-cmake.md +++ b/docs/06_how-to-guides/10_compile/02_how-to-configure-cmake.md @@ -19,7 +19,7 @@ The following steps show: ### Automatic generation of CMake configuration -To compile a smart contract project with CMake, you'll need a CMake file. To use the new `eosio-init` tool to generate the directory structure stub `.hpp/.cpp` files and the CMake configuration files follow these steps: +To compile a smart contract project with CMake, you'll need a CMake file. To use the new `cdt-init` tool to generate the directory structure stub `.hpp/.cpp` files and the CMake configuration files follow these steps: ```sh cd ~ diff --git a/docs/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md b/docs/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md index cc84cbbc05..cd72d3c56d 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md @@ -54,7 +54,7 @@ Add the data structure data members. Each data member corresponds to a field of ### 3. Define The Primary Index -Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (eosio-cpp) will generate an error saying it can not find the field to use as the primary key: +Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key: ```diff // the data structure which defines each row of the table @@ -116,7 +116,7 @@ Declare the `testtab` multi-index table as a data member of type `test_table_t`. Now you have instantiated a multi-index table, and assigned to `testtab` variable, which has a primary index defined for its `test_primary` data member. [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md b/docs/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md index 68dea63de0..80ede16ea6 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md @@ -116,7 +116,7 @@ __multi_index_example.hpp__ Now you have instantiated the `testtab` as a multi-index table which has a primary index defined for its `test_primary` data member and a secondary index for its `secondary` data member. [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). [[warning | Do not add a secondary index to an existing table]] | Adding a secondary index to an existing multi-index table it will have unpredictable outcome. Consult the [Data design and migration](../best-practices/data-design-and-migration) documentation for more details. diff --git a/docs/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md b/docs/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md index e57cebe0a0..846dc3263e 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md @@ -146,7 +146,7 @@ __singleton_example.cpp__ ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of singleton can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/singleton_example). +| A full example project demonstrating the instantiation and usage of singleton can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md b/docs/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md index 80db74dcee..5262c1c9eb 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md @@ -54,7 +54,7 @@ Check to see if the user exists and use [`erase`(...)](../../group__multiindex/# ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md b/docs/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md index f2c8537692..874a01c8ef 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md @@ -59,7 +59,7 @@ Use the [`emplace`](../../group__multiindex/#function-emplace) method to make th ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md b/docs/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md index 101f6169ef..a8b4c6911e 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md @@ -54,7 +54,7 @@ Add the data structure data members. Each data member corresponds to a field of ### 3. Define The Primary Index -Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (eosio-cpp) will generate an error saying it can not find the field to use as the primary key: +Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key: ```diff // the data structure which defines each row of the table @@ -173,7 +173,7 @@ class [[eosio::contract]] multi_index_example : public contract { ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md b/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md index c4205a1cbe..3ef618f6ca 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md @@ -155,7 +155,7 @@ __multi_index_example.cpp__ ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md b/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md index e821261c42..baabaf5952 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md @@ -139,7 +139,7 @@ __multi_index_example.cpp__ ``` [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md b/docs/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md index 496a841ec6..aa5d218fef 100644 --- a/docs/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md +++ b/docs/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md @@ -80,7 +80,7 @@ If the `user` object you want to update is found, the [`eosio::check`](../../nam Now you have implemented a new action `mod`. Call `mod` to update the `datum` data member for the user object identified by the `user` name parameter. [[info | Full example location]] -| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md b/docs/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md index ddd97794b8..8fefa3117a 100644 --- a/docs/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md +++ b/docs/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md @@ -87,7 +87,7 @@ multi_index_example::mod_action modaction("multiindexex"_n, {get_self(), 1}); +modaction.send("eostutorial"_n, 1); ``` -For a full example see the [`multi_index` contract implementation](https://github.com/EOSIO/eosio.cdt/tree/master/examples/multi_index_example). +For a full example see the [multi_index example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example). ## Summary diff --git a/docs/06_how-to-guides/60_how-to-return-values-from-actions.md b/docs/06_how-to-guides/60_how-to-return-values-from-actions.md index eaf7c8c805..c4af5ba7f9 100644 --- a/docs/06_how-to-guides/60_how-to-return-values-from-actions.md +++ b/docs/06_how-to-guides/60_how-to-return-values-from-actions.md @@ -64,7 +64,7 @@ action_response smrtcontract::checkwithrv( name nm ) { } ``` -For a complete example of a smart contract that implements an action which returns a value see the [hello example smart contract](https://github.com/EOSIO/eosio.cdt/blob/develop/examples/hello/src/hello.cpp#L16). +For a complete example of a smart contract that implements an action which returns a value see the [hello example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/hello). ## Next Steps diff --git a/docs/07_best-practices/07_error_handling.md b/docs/07_best-practices/07_error_handling.md index 549a21ce59..645b7b5a30 100644 --- a/docs/07_best-practices/07_error_handling.md +++ b/docs/07_best-practices/07_error_handling.md @@ -2,18 +2,18 @@ content_title: Error handling --- -Contracts can use `uint64_t` error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, EOSIO and EOSIO.CDT reserve certain ranges of the `uint64_t` value space for their own purposes. Contract developers must be aware of the following ranges and restrictions: +Contracts can use `uint64_t` error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, Antelope and CDT reserve certain ranges of the `uint64_t` value space for their own purposes. Contract developers must be aware of the following ranges and restrictions: 1. $0 - 4,999,999,999,999,999,999$: Available for contract developers to assign error codes specific to their contracts. 2. $5,000,000,000,000,000,000 - 7,999,999,999,999,999,999$: -Reserved for the EOSIO.CDT compiler to allocate as appropriate. Although the WASM code generated by the EOSIO.CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file). +Reserved for the CDT compiler to allocate as appropriate. Although the WASM code generated by the CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file). 3. $8,000,000,000,000,000,000 - 9,999,999,999,999,999,999$: -Reserved for the EOSIO.CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by EOSIO.CDT. +Reserved for the CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by CDT. 4. $10,000,000,000,000,000,000 - 18,446,744,073,709,551,615$: -Reserved for EOSIO to represent system-level error conditions. EOSIO will actually enforce this by restricting the ability for `eosio_assert_code` to be used to fail with error code values used within this range. +Reserved by the Antelope protocol to represent protocol-level error conditions. Antelope will actually enforce this by restricting the ability for `eosio_assert_code` to be used to fail with error code values used within this range. Therefore, contract developers should only reserve error codes from the first range above to use in their contracts. diff --git a/docs/07_best-practices/08_abi/00_understanding-abi-files.md b/docs/07_best-practices/08_abi/00_understanding-abi-files.md index 1cb7e9995e..a6cf46a8a9 100644 --- a/docs/07_best-practices/08_abi/00_understanding-abi-files.md +++ b/docs/07_best-practices/08_abi/00_understanding-abi-files.md @@ -4,7 +4,7 @@ link_text: "Understanding ABI Files" --- ## Introduction -ABI files can be generated using the `eosio-cpp` utility provided by `eosio.cdt`. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary. +ABI files can be generated using the `cdt-cpp` utility provided by CDT. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary. ## What is an ABI @@ -35,7 +35,7 @@ Start with an empty ABI, for exemplification we will work based on the `eosio.to An ABI enables any client or interface to interpret and even generate a GUI for your contract. For this to work consistently, describe the custom types that are used as a parameter in any public action or struct that needs to be described in the ABI. [[info | Built-in Types]] -| EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/EOSIO/eos/blob/76565937064d5acccb089b50aa8ea797cd92dc82/libraries/chain/abi_serializer.cpp#L90) +| EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/AntelopeIO/leap/blob/6817911900a088c60f91563995cf482d6b380b2d/libraries/chain/abi_serializer.cpp#L88-L129) ```json diff --git a/docs/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md b/docs/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md index 737b9276ac..2c704372bc 100644 --- a/docs/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md +++ b/docs/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md @@ -81,7 +81,7 @@ void some_function(...) { } ``` -The code above will mark an arbitrary function as an entry point, which will then wrap the function with global constructors (ctors) and global destructors (dtors). This will allow for the eosio.cdt toolchain to produce WASM binaries for other ecosystems. +The code above will mark an arbitrary function as an entry point, which will then wrap the function with global constructors (ctors) and global destructors (dtors). This will allow for the CDT toolchain to produce WASM binaries for other ecosystems. ## [[eosio::wasm_import]] ```cpp @@ -113,4 +113,4 @@ Contract actions tagged read-only: * Cannot call `inline actions`. * The amount of data returned by read-only queries is limited by the action return value size. By default these are set to 256 bytes by `default_max_action_return_value_size`. -The `eosio-cpp` and `eosio-cc` tools will generate an error and terminate compilation if an action tagged read-only attempts to call insert/update (write) functions, `deferred transactions` or `inline actions`. However, if the command-line override option `--warn-action-read-only` is used, the `eosio-cpp` and `eosio-cc` tools will issue a warning and continue compilation. +The `cdt-cpp` and `cdt-cc` tools will generate an error and terminate compilation if an action tagged read-only attempts to call insert/update (write) functions, `deferred transactions` or `inline actions`. However, if the command-line override option `--warn-action-read-only` is used, the `cdt-cpp` and `cdt-cc` tools will issue a warning and continue compilation. diff --git a/docs/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md b/docs/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md index 4b249ac9a6..b67bee83c3 100644 --- a/docs/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md +++ b/docs/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md @@ -11,5 +11,5 @@ link_text: Manually write/edit an ABI file - The Ricardian contracts should be housed in a file with the name `.contracts.md` and the clauses should be in a file named `.clauses.md`. - For each Ricardian contract the header `

ActionName

` should be used, as this directs the ABI generator to attach this Ricardian contract to the specified action. - For each Ricardian clause, the header `

ClauseID

` should be used, as this directs the ABI generator to the clause id and the subsequent body. - - The option `-R` has been added to [`eosio-cpp`](../../03_command-reference/eosio-cpp.md) and [`eosio-abigen`](../../03_command-reference/eosio-abigen.md) to add "resource" paths to search from, so you can place these files in any directory structure you like and use `-R` in the same vein as `-I` for include paths. - - For exemplification see [hello.contracts.md](https://github.com/EOSIO/eosio.cdt/blob/master/examples/hello/ricardian/hello.contracts.md). + - The option `-R` has been added to [`cdt-cpp`](../../03_command-reference/cdt-cpp.md) to add "resource" paths to search from, so you can place these files in any directory structure you like and use `-R` in the same vein as `-I` for include paths. + - For exemplification see [hello.contracts.md](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/ricardian/hello.contracts.md). diff --git a/docs/07_best-practices/11_debugging_a_smart_contract.md b/docs/07_best-practices/11_debugging_a_smart_contract.md index 2debfd3f4b..8f0fad364e 100644 --- a/docs/07_best-practices/11_debugging_a_smart_contract.md +++ b/docs/07_best-practices/11_debugging_a_smart_contract.md @@ -100,7 +100,7 @@ extern "C" { Deploy it and push an action to it. It is assumed you have a `debug` account created and have its key in your wallet. ```bash -$ eosio-cpp -abigen debug.cpp -o debug.wasm +$ cdt-cpp -abigen debug.cpp -o debug.wasm $ cleos set contract debug CONTRACT_DIR/debug -p youraccount@active $ cleos push action debug foo '{"from":"inita", "to":"initb", "amount":10}' --scope debug ``` diff --git a/docs/08_troubleshooting/index.md b/docs/08_troubleshooting/index.md index b16eb7f621..7ba4105c3e 100644 --- a/docs/08_troubleshooting/index.md +++ b/docs/08_troubleshooting/index.md @@ -89,9 +89,9 @@ Couldn't parse type_name __Possible solution__: It is possible that you changed the type of the fields for the table struct definition? If you need to change the table structure definition there are some limitations and a couple of ways to do it which are explained in the [Data Design and Migration](./07_best-practices/04_data-design-and-migration.md) section. -## eosio-cpp process never completes +## cdt-cpp process never completes -__Possible solution__: make sure you have at least 2 cores on the host that executes the eosio-cpp (e.g. docker container, VM, local sub-system) +__Possible solution__: make sure you have at least 2 cores on the host that executes the cdt-cpp (e.g. docker container, VM, local sub-system) ## You can not find the `now()` time function, or the result of the `current_time_point` functions are not what you expected them to be diff --git a/docs/09_tutorials/01_binary-extension.md b/docs/09_tutorials/01_binary-extension.md index 5c7b291794..e02590e316 100644 --- a/docs/09_tutorials/01_binary-extension.md +++ b/docs/09_tutorials/01_binary-extension.md @@ -2,7 +2,7 @@ content_title: eosio::binary_extension --- -You can find the implementation of `eosio::binary_extension` in the `eosio.cdt` repository in [binary_extension.hpp](https://github.com/EOSIO/eosio.cdt/blob/master/libraries/eosiolib/binary_extension.hpp). +You can find the implementation of `eosio::binary_extension` within the CDT repository in the file [binary_extension.hpp](https://github.com/AntelopeIO/cdt/blob/main/libraries/eosiolib/core/eosio/binary_extension.hpp). The primary concern when using this type is when you are adding a new field to a smart contract's data structure that is currently utilized in an `eosio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration. @@ -360,7 +360,7 @@ Find below their corresponding sections in the `.abi` files:
Start up a blockchain instance, compile this smart contract, and test it out. ``` -~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm +~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm ``` ``` @@ -503,7 +503,7 @@ struct [[eosio::table]] structure { Next, upgrade the contract and try to read from table and write to table the original way: ``` -~/binary_extension_contract $ eosio-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm +~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm ``` ``` diff --git a/docs/09_tutorials/02_abi-variants.md b/docs/09_tutorials/02_abi-variants.md index d085b2dcaf..a5bc46d179 100644 --- a/docs/09_tutorials/02_abi-variants.md +++ b/docs/09_tutorials/02_abi-variants.md @@ -155,7 +155,4 @@ class [[eosio::contract]] multi_index_example : public contract { ``` [[warning | Not recommended warning]] -| Be aware, it is not recommend to use `eosio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated! - -[[info | Implementation location]] -| The implementation for ABI `variants` can be found [here](https://github.com/EOSIO/eos/pull/5652). +| Be aware, it is not recommend to use `eosio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated! \ No newline at end of file diff --git a/docs/09_tutorials/03_create-an-abi-file.md b/docs/09_tutorials/03_create-an-abi-file.md index 265f0d4a30..23d62e40ae 100644 --- a/docs/09_tutorials/03_create-an-abi-file.md +++ b/docs/09_tutorials/03_create-an-abi-file.md @@ -4,10 +4,7 @@ content_title: Create an ABI File ## Overview -This tutorial provides instructions to create an ABI file. - -[[warning]] -| As of v1.2.0, the eosio.wasmsdk was decoupled from the core repository. This change has introduced an eosio-cpp regression where the legacy eosio-abigen is no longer bundled with eosio-cpp. Until a new ABI generator is introduced, you will need to hand-write your ABI files. +This tutorial provides instructions to how to hand-write an ABI file. This should normally not be necessary since `cdt-cpp` can automatically generate an ABI file from your source code if it is properly annotated. ## Introduction @@ -38,7 +35,7 @@ An ABI enables any client or interface to interpret and even generate an GUI for [[info]] |Built-in Types -EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/EOSIO/eos/blob/master/libraries/chain/abi_serializer.cpp#L65-L103). +EOSIO implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with EOSIO's built-ins, they are defined [here](https://github.com/AntelopeIO/leap/blob/6817911900a088c60f91563995cf482d6b380b2d/libraries/chain/abi_serializer.cpp#L88-L129). Using **eosio.token** as an example, the only type that requires a description in the ABI file is `account_name`. The ABI uses "new_type_name" to describe explicit types, in this case `account_name`, and `account_name` is an alias of `name` type. diff --git a/docs/index.md b/docs/index.md index 0090445cbb..289ae23de2 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,20 +1,13 @@ -# EOSIO.CDT (Contract Development Toolkit) +# CDT (Contract Development Toolkit) -EOSIO.CDT is a toolchain for WebAssembly (WASM) and set of tools to facilitate smart contract development for the EOSIO platform. In addition to being a general purpose WebAssembly toolchain, [Mandel](https://github.com/eosnetworkfoundation/mandel) specific optimizations are available to support building EOSIO smart contracts. This new toolchain is built around [Clang 9](https://github.com/eosnetworkfoundation/cdt-llvm), which means that EOSIO.CDT has the most currently available optimizations and analyses from LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available. +Contract Development Toolkit (CDT) is a C/C++ toolchain targeting WebAssembly (WASM) and a set of tools to facilitate development of smart contracts written in C/C++ that are meant to be deployed to an [Antelope](https://github.com/AntelopeIO/) blockchain. -## Upgrading - -There's been a round of braking changes, if you are upgrading from an older version please read [Upgrading CDT to Mandel](./04_upgrading/eosio.cdt-to-mandel.cdt.md). +In addition to being a general purpose WebAssembly toolchain, specific features and optimizations are available to support building Antelope-based smart contracts. This new toolchain is built around [Clang 9](https://github.com/AntelopeIO/cdt-llvm), which means that CDT inherits the optimizations and analyses from that version of LLVM, but as the WASM target is still considered experimental, some optimizations are incomplete or not available. -## Contributing +## Upgrading -See the [Contributing Guide](https://github.com/eosnetworkfoundation/mandel/blob/main/CONTRIBUTING.md) +If you are upgrading to CDT version 3.0 or later from version 1.8.1 (or earlier) of [EOSIO.CDT](https://github.com/EOSIO/eosio.cdt), then please read [EOSIO.CDT to CDT](./04_upgrading/eosio.cdt-to-cdt.md). ## License -[MIT](./../LICENSE) - -## Important - -See LICENSE for copyright and license terms. Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, service or other resource is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. - +[MIT](../LICENSE) diff --git a/examples/hello/README.txt b/examples/hello/README.txt index 62876f1852..56c1ae60bd 100644 --- a/examples/hello/README.txt +++ b/examples/hello/README.txt @@ -11,9 +11,9 @@ - Additions to cmake should be done to the CMakeLists.txt in the './src' directory and not in the top level CMakeLists.txt - -- How to build with eosio-cpp -- + -- How to build with cdt-cpp -- - cd into the 'build' directory - - run the command 'eosio-cpp -abigen ../src/hello.cpp -o hello.wasm -I ../include/' + - run the command 'cdt-cpp -abigen ../src/hello.cpp -o hello.wasm -I ../include/' - After build - - The built smart contract is in the 'build' directory diff --git a/examples/multi_index_example/README.txt b/examples/multi_index_example/README.txt index 6472e46aeb..578198ef48 100644 --- a/examples/multi_index_example/README.txt +++ b/examples/multi_index_example/README.txt @@ -11,9 +11,9 @@ - Additions to CMake should be done to the CMakeLists.txt in the './src' directory and not in the top level CMakeLists.txt - -- How to build with eosio-cpp -- + -- How to build with cdt-cpp -- - cd into the 'build' directory - - run the command 'eosio-cpp -abigen ../src/multi_index_example.cpp -o multi_index_example.wasm -I ../include/' + - run the command 'cdt-cpp -abigen ../src/multi_index_example.cpp -o multi_index_example.wasm -I ../include/' - After build - - The built smart contract is in the 'build' directory diff --git a/examples/multi_index_large/README.txt b/examples/multi_index_large/README.txt index 770e7371d4..5797be87ef 100644 --- a/examples/multi_index_large/README.txt +++ b/examples/multi_index_large/README.txt @@ -11,9 +11,9 @@ - Additions to CMake should be done to the CMakeLists.txt in the './src' directory and not in the top level CMakeLists.txt - -- How to build with eosio-cpp -- + -- How to build with cdt-cpp -- - cd into the 'build' directory - - run the command 'eosio-cpp -abigen ../src/multi_index_large.cpp -o multi_index_large.wasm -I ../include/' + - run the command 'cdt-cpp -abigen ../src/multi_index_large.cpp -o multi_index_large.wasm -I ../include/' - After build - - The built smart contract is in the 'build' directory diff --git a/examples/send_inline/README.txt b/examples/send_inline/README.txt index cc86cbc385..6c5d75d641 100644 --- a/examples/send_inline/README.txt +++ b/examples/send_inline/README.txt @@ -11,9 +11,9 @@ - Additions to CMake should be done to the CMakeLists.txt in the './src' directory and not in the top level CMakeLists.txt - -- How to build with eosio-cpp -- + -- How to build with cdt-cpp -- - cd into the 'build' directory - - run the command 'eosio-cpp -abigen ../src/send_inline.cpp -o send_inline.wasm -I ../include/ -I ../../hello/include/' + - run the command 'cdt-cpp -abigen ../src/send_inline.cpp -o send_inline.wasm -I ../include/ -I ../../hello/include/' - After build - - The built smart contract is in the 'build' directory diff --git a/examples/singleton_example/README.txt b/examples/singleton_example/README.txt index 8d948e46a0..06b7c198bd 100644 --- a/examples/singleton_example/README.txt +++ b/examples/singleton_example/README.txt @@ -11,9 +11,9 @@ - Additions to CMake should be done to the CMakeLists.txt in the './src' directory and not in the top level CMakeLists.txt - -- How to build with eosio-cpp -- + -- How to build with cdt-cpp -- - cd into the 'build' directory - - run the command 'eosio-cpp -abigen ../src/singleton_example.cpp -o singleton_example.wasm -I ../include/' + - run the command 'cdt-cpp -abigen ../src/singleton_example.cpp -o singleton_example.wasm -I ../include/' - After build - - The built smart contract is in the 'build' directory diff --git a/modules/TestsExternalProject.txt b/modules/TestsExternalProject.txt index 8c6da2be71..ad32c7ed5f 100644 --- a/modules/TestsExternalProject.txt +++ b/modules/TestsExternalProject.txt @@ -6,7 +6,7 @@ ExternalProject_Add( CDTWasmTests SOURCE_DIR "${CMAKE_SOURCE_DIR}/tests/unit" BINARY_DIR "${CMAKE_BINARY_DIR}/tests/unit" - CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE=${CMAKE_BINARY_DIR}/lib/cmake/cdt/CDTWasmToolchain.cmake -DCMAKE_BUILD_TYPE=Release -DCDT_BIN=${CMAKE_BINARY_DIR}/lib/cmake/cdt/ -DBASE_BINARY_DIR=${CMAKE_BINARY_DIR} -D__APPLE=${APPLE} -DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH} -DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH} -Dmandel_DIR=${mandel_DIR} + CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE=${CMAKE_BINARY_DIR}/lib/cmake/cdt/CDTWasmToolchain.cmake -DCMAKE_BUILD_TYPE=Release -DCDT_BIN=${CMAKE_BINARY_DIR}/lib/cmake/cdt/ -DBASE_BINARY_DIR=${CMAKE_BINARY_DIR} -D__APPLE=${APPLE} -DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH} -DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH} UPDATE_COMMAND "" PATCH_COMMAND "" TEST_COMMAND "" @@ -16,9 +16,9 @@ ExternalProject_Add( ) -find_package(eosio QUIET) +find_package(leap QUIET) -if (eosio_FOUND) +if (leap_FOUND) if(CMAKE_BUILD_TYPE STREQUAL "Debug") set(TEST_BUILD_TYPE "Debug") set(CMAKE_BUILD_TYPE "Release") @@ -41,5 +41,5 @@ if (eosio_FOUND) BUILD_ALWAYS 1 ) else() - message(STATUS "mandel package not found, skipping building integration tests") -endif() \ No newline at end of file + message(STATUS "leap package not found, skipping building integration tests") +endif() diff --git a/scripts/generate_package.sh.in b/scripts/generate_package.sh.in index 013fe9c970..1e8d438799 100644 --- a/scripts/generate_package.sh.in +++ b/scripts/generate_package.sh.in @@ -16,7 +16,7 @@ VERSION_SUFFIX="@VERSION_SUFFIX@" VERSION="@VERSION_FULL@" # Using CMAKE_BINARY_DIR uses an absolute path and will break cross-vm building/download/make functionality -BUILD_DIR="../../build" +BUILD_DIR="../" VENDOR="@VENDOR@" PROJECT="@PROJECT_NAME@" diff --git a/scripts/generate_tarball.sh b/scripts/generate_tarball.sh index 210912dc27..271e511894 100644 --- a/scripts/generate_tarball.sh +++ b/scripts/generate_tarball.sh @@ -49,7 +49,7 @@ fi # make symlinks pushd ${PREFIX}/lib/cmake/${PROJECT} &> /dev/null ln -sf ../../../${SUBPREFIX}/lib/cmake/${PROJECT}/${PROJECT}-config.cmake ${PROJECT}-config.cmake || exit 1 -ln -sf ../../../${SUBPREFIX}/lib/cmake/${PROJECT}/CDTToolchain.cmake CDTWasmToolchain.cmake || exit 1 +ln -sf ../../../${SUBPREFIX}/lib/cmake/${PROJECT}/CDTWasmToolchain.cmake CDTWasmToolchain.cmake || exit 1 ln -sf ../../../${SUBPREFIX}/lib/cmake/${PROJECT}/CDTMacros.cmake CDTMacros.cmake || exit 1 popd &> /dev/null diff --git a/tests/integration/CMakeLists.txt b/tests/integration/CMakeLists.txt index 57c898bd89..6d74a80088 100644 --- a/tests/integration/CMakeLists.txt +++ b/tests/integration/CMakeLists.txt @@ -4,7 +4,7 @@ set(EOSIO_VERSION_MIN "3.1") set(EOSIO_VERSION_SOFT_MAX "3.1") #set(EOSIO_VERSION_HARD_MAX "") -find_package(eosio) +find_package(leap) find_path(GMP_INCLUDE_DIR NAMES gmp.h) find_library(GMP_LIBRARY gmp) @@ -17,11 +17,11 @@ EOSIO_CHECK_VERSION(VERSION_OUTPUT "${EOSIO_VERSION}" "${EOSIO_VERSION_HARD_MAX}" VERSION_MATCH_ERROR_MSG) if(VERSION_OUTPUT STREQUAL "MATCH") - message(STATUS "Using eosio version ${EOSIO_VERSION}") + message(STATUS "Using Leap version ${EOSIO_VERSION}") elseif(VERSION_OUTPUT STREQUAL "WARN") - message(WARNING "Using eosio version ${EOSIO_VERSION} even though it exceeds the maximum supported version of ${EOSIO_VERSION_SOFT_MAX}; continuing with configuration, however build may fail.\nIt is recommended to use eosio version ${EOSIO_VERSION_SOFT_MAX}.x") + message(WARNING "Using Leap version ${EOSIO_VERSION} even though it exceeds the maximum supported version of ${EOSIO_VERSION_SOFT_MAX}; continuing with configuration, however build may fail.\nIt is recommended to use Leap version ${EOSIO_VERSION_SOFT_MAX}.x") else() # INVALID OR MISMATCH - message(FATAL_ERROR "Found eosio version ${EOSIO_VERSION} but it does not satisfy version requirements: ${VERSION_MATCH_ERROR_MSG}\nPlease use eosio version ${EOSIO_VERSION_SOFT_MAX}.x") + message(FATAL_ERROR "Found Leap version ${EOSIO_VERSION} but it does not satisfy version requirements: ${VERSION_MATCH_ERROR_MSG}\nPlease use Leap version ${EOSIO_VERSION_SOFT_MAX}.x") endif(VERSION_OUTPUT STREQUAL "MATCH") diff --git a/tests/unit/version_tests.sh b/tests/unit/version_tests.sh index 419010f76e..b08d9ccc0f 100755 --- a/tests/unit/version_tests.sh +++ b/tests/unit/version_tests.sh @@ -1,7 +1,7 @@ #!/bin/bash set -eo pipefail # The purpose of this test is to ensure that the output of the "cdt-cpp --version" command matches the version string defined by our CMake files -echo '##### Eosio-cpp Version Label Test #####' +echo '##### cdt-cpp Version Label Test #####' # orient ourselves [[ -z "$BUILD_ROOT" ]] && export BUILD_ROOT="$(pwd)" echo "Using BUILD_ROOT=\"$BUILD_ROOT\"." @@ -24,7 +24,7 @@ ACTUAL=$($BUILD_ROOT/bin/cdt-cpp --version) EXIT_CODE=$? # verify 0 exit code explicitly if [[ $EXIT_CODE -ne 0 ]]; then - echo "Eosio-cpp produced non-zero exit code \"$EXIT_CODE\"." + echo "cdt-cpp produced non-zero exit code \"$EXIT_CODE\"." exit $EXIT_CODE fi # test version