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 hover tool adds another template file named hooks.go in the ./desktop/cmd directory.
The content of the file is the following:
// +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 hooks.go with the following content:
// +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 -tags=hooks isn't provided, no dead code in the final exec.
Plugin can then satisfy the Hook interface to run post build copy.
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:
go run -tags=hooks -ldflags='-X main.buildPath=/tmp/test -X main.projectPath=/tmp/test/desktop/build/outputs/linux' ../../../cmd/options.go ../../../cmd/hooks.go
from the output/{GOOS} directory to run all AfterBuildHook.
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?
@djpnewton can you explain what your build looks like? What file do you add to the folder that is erased?
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 https://github.com/go-flutter-desktop/hover/pull/12#issuecomment-519438280 hit master, the --omit-embedder flag will be available, using this flag the build directory won't be deleted.
It's a workaround (and a dirty one).
Awwwwwh, we were so focus on plugins/hooks that we forgot you old and trusty go/assets directory...
If you place file in go/assets the hover tool-chain will always copy the content of that directory to go/build/outputs/XXXXX/assets.
Closing the issue since the original request was:
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.
The answer is to place them into the go/assets directory. :1st_place_medal:
FYI: I've written a small example about dart:ffi and go-flutter in https://github.com/go-flutter-desktop/go-flutter/issues/58#issuecomment-530375169
There are still a couple of issues:
1) Most platform load library functions look in the same dir as the exe or the system (say Android) makes sure to add certain directories into the load library search space, using "assets/" means we need different load library path logic for different platforms
2) The loaded libraries might rely on other resources and not being able to put them in a arbitrary place might hinder this
How does the go/assets dir work? Maybe we could reuse this functionality to with a command line parameter or something?
Most platform load library functions look in the same dir as the exe or the system (say Android) makes sure to add certain directories into the load library search space, using "assets/" means we need different load library path logic for different platforms.
Humm, for classic share libraries that the exec needs, yes I agree, but, does it applies to Foreign function interface?
The loaded libraries might rely on other resources and not being able to put them in a arbitrary place might hinder this
IMHO, I don't thinks it's a go-flutter problem.
How does the go/assets dir work?
On every hover run | hover build the content of the go/asset dir gets copied to go/build/outputs/linux/assets
I thinks the discussion drift away.
we need the option to not delete the output directory or perhaps some hook to copy files into the build output directory
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: https://github.com/go-flutter-desktop/go-flutter/issues/296#issuecomment-550521895