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

Let users specify different targets #26

Open
Tracked by #3921
kritzcreek opened this issue Apr 13, 2021 · 2 comments
Open
Tracked by #3921

Let users specify different targets #26

kritzcreek opened this issue Apr 13, 2021 · 2 comments

Comments

@kritzcreek
Copy link
Collaborator

It's common to have library and test targets with different dependencies and I can think of more possible targets like benchmarks, or maybe even canisters/canister blueprints.

In my library template I "solve" this by referencing the main vessel.dhall from the test folder and extending it using Dhall. It's not ideal because it creates a separate .vessel directory underneath test/. And requires running test commands from within test/, but I also don't hate having the test specific configuration in the test/ directory rather than adding it to the library config.

Possible Solution 1:
spago solves this by letting the user specify a config file to use instead of the default one. So you'd create a test.dhall file and call something like vessel -x test/test.dhall sources.

Possible Solution 2:
cargo and most other package managers let the user specify their multiple targets in the main manifest file, We could come up with a schema to do the same for vessel.

Related to/Generalizes #7

@matthewhammer
Copy link

Seems like "possible solution 1" is what I actually did in practice, and that vessel already supports this now, via --package-set?

My interpretation of solution 2 (the popular way / the "cargo way") is as a systematic pre-arranged structure for these extra files' contents, and rules about combining them (example binaries vs test libraries and binaries vs "main crate"), though I may not appreciate what cargo is doing entirely.

@matthewhammer
Copy link

Seems like "possible solution 1" is what I actually did in practice

And IIUC, I could refactor these files to reduce the redundancy and have one use the other, following what you do in the library template. I am taking Dhall baby steps for now, but I think that's another natural baby step in the right direction.

@crusso crusso mentioned this issue Apr 4, 2023
79 tasks
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

No branches or pull requests

2 participants