Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed top level Cargo.toml to have individual examples not be managed under a virtual workspace #232

Merged
merged 23 commits into from
Apr 22, 2023

Conversation

anupsdf
Copy link
Contributor

@anupsdf anupsdf commented Apr 19, 2023

What

Making the Soroban Examples as independent projects.

  • Removed top level Cargo.toml to have individual examples not be managed under a virtual workspace.
  • Moved all the dependencies and dev-dependencies from top level Cargo.toml to individual examples's Cargo.toml file. It was mostly soroban-sdk and some had soroban-auth.
  • Each project (example) would have its own Makefile that would be called by the root Makefile

Side note: For soroban-sdk dependency providing version alone works. So I didn't include git and rev that top level Cargo.toml had.

Why

We are doing this because each example can be individually managed. User will go to each example directory, build them and invoke the soroban contract. For some of the examples where there is a package dependency, they would have to build the packages in the right order. In future we can use artifact-dependency when it becomes available in stable rust channel.

Copy link
Member

@leighmcculloch leighmcculloch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this is going to be easier for developers approaching the repo from the docs.

Could we also:

  • Add a Makefile for each project that does the basic build / test like the root one does, with the build step doing a build of any dependency in the examples repo as well?
  • Update the Makefile in the root to run build / test on all the sub-folder's make files?

Makefile Outdated Show resolved Hide resolved
.gitpod.yml Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
@anupsdf anupsdf marked this pull request as draft April 20, 2023 19:22
Makefile Outdated Show resolved Hide resolved
timelock/Makefile Outdated Show resolved Hide resolved
@anupsdf anupsdf self-assigned this Apr 21, 2023
@anupsdf anupsdf marked this pull request as ready for review April 21, 2023 02:33
@anupsdf anupsdf requested a review from sisuresh April 21, 2023 03:25
@anupsdf anupsdf requested a review from dmkozh April 21, 2023 03:25
Makefile Outdated Show resolved Hide resolved
Copy link
Member

@leighmcculloch leighmcculloch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏🏻 Looks good to me.

@anupsdf
Copy link
Contributor Author

anupsdf commented Apr 21, 2023

Expanding the job fmt shows that the shell command didn't run. I will make another change to use command in the run step to see if it works.

UPDATE 2: Switched to make fmt instead in rust.yml file. Now fmt job runs fine.
UPDATE: Used parenthesis to run the shell script with special characters. Waiting for the workflow job to complete to see the result.

@leighmcculloch leighmcculloch merged commit 4cf3897 into stellar:main Apr 22, 2023
chadoh added a commit to AhaLabs/soroban-examples that referenced this pull request Apr 25, 2023
Since stellar#232, these are no longer members of a workspace, and now running
`make build` in the root adds a `target` and `Cargo.lock` to each
directory.

This ignores each such `target`, but adds all the `Cargo.lock` files to
version history.
chadoh added a commit to AhaLabs/soroban-examples that referenced this pull request Nov 27, 2024
Fixes stellar#328

Undoes stellar#232

Forked from stellar#330

Add top-level `Cargo.toml`, with all project folders as part of this
workspace.

We now encourage everyone to use Cargo workspaces when
building Soroban projects. Let's make it easy to copy-paste these
examples into their projects, rather than requiring special tooling
(like the old `stellar contract init` behavior) to update the contract's
Cargo.toml.

Currently, there are two compilation errors when attempting to run
tests:

```
error[E0433]: failed to resolve: use of undeclared crate or module `__get_allowance`
  --> token/src/contract.rs:67:12
   |
67 |     pub fn get_allowance(e: Env, from: Address, spender: Address) -> Option<AllowanceValue> {
   |            ^^^^^^^^^^^^^ use of undeclared crate or module `__get_allowance`
   |
help: there is a crate or module with a similar name
   |
67 |     pub fn __allowance(e: Env, from: Address, spender: Address) -> Option<AllowanceValue> {
   |            ~~~~~~~~~~~

error[E0223]: ambiguous associated type
  --> bls_signature/src/lib.rs:78:18
   |
78 |         agg_sig: Self::Signature,
   |                  ^^^^^^^^^^^^^^^ help: use fully-qualified syntax: `<IncrementContractArgs as soroban_sdk::testutils::ed25519::Sign>::Signature`
```
chadoh added a commit to AhaLabs/soroban-examples that referenced this pull request Nov 27, 2024
Fixes stellar#328

Undoes stellar#232

Forked from stellar#330

Add top-level `Cargo.toml`, with all project folders as part of this
workspace.

We now encourage everyone to use Cargo workspaces when
building Soroban projects. Let's make it easy to copy-paste these
examples into their projects, rather than requiring special tooling
(like the old `stellar contract init` behavior) to update the contract's
Cargo.toml.

Currently, there are two compilation errors when attempting to run
tests:

```
error[E0433]: failed to resolve: use of undeclared crate or module `__get_allowance`
  --> token/src/contract.rs:67:12
   |
67 |     pub fn get_allowance(e: Env, from: Address, spender: Address) -> Option<AllowanceValue> {
   |            ^^^^^^^^^^^^^ use of undeclared crate or module `__get_allowance`
   |
help: there is a crate or module with a similar name
   |
67 |     pub fn __allowance(e: Env, from: Address, spender: Address) -> Option<AllowanceValue> {
   |            ~~~~~~~~~~~
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants