-
Notifications
You must be signed in to change notification settings - Fork 71
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
Conversation
…ed together under a workspace
There was a problem hiding this 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 thebuild
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?
There was a problem hiding this 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.
Expanding the job fmt shows that the shell command didn't run. I will make another change to use UPDATE 2: Switched to |
…sively calls each subdirectory.
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.
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` ```
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> { | ~~~~~~~~~~~ ```
What
Making the Soroban Examples as independent projects.
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.