-
Notifications
You must be signed in to change notification settings - Fork 282
Hover: hook system #203
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
Comments
Proposal:the hover tool adds another template file named // +build hooks
package main
// Injected build-time variables
var (
buildPath string
projectPath string
)
func main() {
for _, option := range options {
option.ExecHook(buildPath, projectPath)
}
} go-flutter has a new file named // +build hooks
package flutter
// Hook defines the interface for plugins that needs to trigger custom
// operations upon hover build.
//
// Hook is separated because not all plugins need to have hook.
type Hook interface {
Plugin
AfterBuildHook(string, string)
}
// ExecHook is called by the hover tool after the build is successful.
func (o Option) ExecHook(projectPath string, buildPath string) {
config := config{}
o(&config)
if len(config.plugins) == 0 {
return
}
if hook, ok := (config.plugins[0]).(Hook); ok {
hook.AfterBuildHook(projectPath, buildPath)
}
} Those file aren't compiled if the Example of plugin with hook. // AfterBuildHook hook
func (p *MyPlugin) AfterBuildHook(projectPath string, buildPath string) {
fmt.Println(projectPath)
fmt.Println(buildPath)
} hover will have to call:
from the What I like about this approach; it's in golang, there isn't any kind of hook list to keep tack of. Everything is done without any configuration file, it's all code. What I don't like about this approach; it require the engine shared library to be loaded in order to run the hook. (could be a feature, If you need to check some constant) Opinions are welcome! Edit: adding the hover cache path could be a good idea. |
This is very interesting! I think that hooks via Go is very complex; it needs extra compiling, and code execution time is totally different from the rest of the plugin, which may not be immediately clear to readers of that code. On the other hand it's more cross-platform than a bash script as hook.. Anyway, before going on such an adventure, perhaps it's worth exploring the use cases a bit more? |
basically I am using dart::ffi and have some shared libraries that need to be in the same directory as the resulting binary, for release builds I can add the shared libraries after the build is completed but for "hover run" it makes it difficult without any way to specify to the build system what extra binaries I have and where to place them |
Once go-flutter-desktop/hover#12 (comment) hit master, the It's a workaround (and a dirty one). |
Awwwwwh, we were so focus on plugins/hooks that we forgot you old and trusty Closing the issue since the original request was:
The answer is to place them into the FYI: I've written a small example about dart:ffi and go-flutter in #58 (comment) |
There are still a couple of issues:
How does the |
Humm, for classic share libraries that the exec needs, yes I agree, but, does it applies to Foreign function interface?
IMHO, I don't thinks it's a go-flutter problem.
On every I thinks the discussion drift away.
The request is solved, more discussion about dart:ffi should happens on other thread. (not necessary go-flutter since dart:ffi is in early preview.. and we aren't google...) |
Please refer to: #296 (comment) |
when building using hover the build directory gets erased, this causes trouble if you are using a 3rd party binary like a shared library or something.
we need the option to not delete the output directory or perhaps some hook to copy files into the build output directory
The text was updated successfully, but these errors were encountered: