Executing code during build is a 100% no-go from a security perspective. Especially arbitrary 3rd party code.
So let me rephrase it: > One of the big advantages of Go's build systems is that running > generators is **not** automated. V On Monday, 8 August 2022 at 12:34:43 UTC+2 stalke...@protonmail.ch wrote: > One of the big advantages of many other build systems and for which reason > many Go projects use Makefiles is that running generators is not automated. > > As I see it, the only thing required to make it automatic is annotation to > make note of the sources that generators build off and trigger rerunning it > before the execution of the compilation. > > All that would require is some way to tag files such that if the files > hashes change the generator should be rerun. I probably am not listing all > the ways that this could be done automatically. I mean, go:generate lines > always include filesystem references, either folders or specific files, > these could be automatically checksummed in go.sum to determine when to > automatically run them. > > As I see it, this lack of automatic code generation and the poor > performance of the Go FFI, Cgo, are the two biggest factors that lead to > projects drifting away from Go once someone decides to start putting > foreign code into the mix that they want binary coupling. I think that a > standardised run control system for child processes so foreign language > binaries can interface with minimal work would also go some way to fix this > problem since it isolates the runtimes completely, and in many cases only > introduces a small latency cost. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/aef3e5c1-95ce-452b-802a-f0e948e7b864n%40googlegroups.com.
