Skip to content
New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants