-
Notifications
You must be signed in to change notification settings - Fork 82
Multi and wildcard target support (v2) #67
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
Multi and wildcard target support (v2) #67
Conversation
@jld3103 Introduction: The Leverage mental model (taken from Justin M. Keyes)Leverage = (impact / cost):
Low leverage: shallow features
High leverage: deep extensibility
Analysis of the projectThe Hover source code is spitted across 36 files [1]. Analysis of the PR
ConclusionBased on the analysis of this PR, when we apply the above On your previous PR #52, I suggested 2 propositions:
$ hover build all
$ # vs
$ hover build windows-msi && hover build darwin-bundle && hover build linux-appimage
$ # (excluding `linux-deb`, `linux-snap`,.. because they where not initialized) What do you think of this proposal?
|
I understand. I guess you're right. |
How about the |
That should be the way to go. |
This adds support for multi and wildcard target support.
This uses the previous way for single targets, but makes multi and wildcard targets available using
--packaging-targets
forhover init-packaging
and--build-targets
forhover build
.@pchampio You said that nobody really needs this feature, but I actually need it. I'm building my app using CI where this is used to build all app types.
Anyway this is only an addition to the old format, because as you said the previous way for single targets was much better.
Also adding this target system makes it easier when flutter gets the ability to build 32-bit bundles for Raspberry Pi etc. (Which I hope will come in the near future). Then we only need to add a new field to a
Target
.