3 ms·

> It is important to note that as a matter of both design and policy, the go command never runs user-specified code during a build. This improves the reproducib

• mariusor 5y ago
  Yes, but I think that's mostly wishful thinking. Not all applications get built using strictly go tooling. I rely on make for mine because it's better suited for the platform I'm targeting.
  • q3k 5y ago
    Right, and because your dependencies don't shell out to some random tools during a go build it makes your build system less likely to break and makes your job easier. You have guarantees that unless you run a `go generate` no third-party code will run, and that every build step is fully hermetic. And since you're already using Make for the build, it's probably better equipped to perform the preprocessing than go embed or even go generate so you don't really need Go's build system to take care of that. `go build` & co are designed to easily integrate into complex or overarching build systems (which are inevitable for any large project, as you mentioned), and the lack of expectation of being able to shell out arbitrarily during a 'normal' build of some leaf library is what contributes to this ease of integration. Contrast that to how difficult it is to integrate with Rust/Cargo's build system where every second package has a `build.rs` which expects some undefined ambient environment to be present and makes any attempt to make the builds hermetic extremely painful.