Sorry for clicking the "reply to author" button instead of "reply to all" button.
So the final solution is to use build tags, "//go:build !cmd_go_bootstrap && !compiler_bootstrap" or "//go:build cmd_go_bootstrap || compiler_bootstrap". Thanks for your replies. --- On Tue, Jul 15, 2025 at 6:57 PM Qingwei Li wrote: > > The advantage might be consistency among stage1, 2 and 3? One code for 3 stages. Besides, developers don't need to worry about different behaviours among stage1 and 2/3. > > But I don't know the reason why bootstrap does not support vendored package. Since stage2 and 3 import vendored packages, security(e.g. supply chain attack) and maintainance(e.g. vendor package may require different version of go) issues exist no matter stage1 supports vendored packages, while using go:build tags in stage1 can add more complexity. (But the advantage of tags is that dependencies to vendored packages can be placed in a separated file, like counter_bootstrap.go/counter.go, which leads a cleaner project with all adapters placed in separate files. But it brings complexity as forementioned) > I guess that if vendor package is used, then go1.4(the old bootstrap) can not build some vendor packages which requires higher version of go. But in recent versions of go, the version of GOROOT_BOOTSTRAP is higher and https://github.com/golang/go/issues/54265 says that bootstrap version will be bumped forward once a year, so the forementioned restriction can be relaxed now. I'm just guessing. In general please write to the mailing list, not just to me. Thanks. I don't see a reason to do any work to support vendored packages in stage 1 unless there is some specific vendored package that make a big difference. The capabilities of stage 1 are not very important. It's stage 3 that matters. Stage 1 just has to be good enough to build stage 2. Ian On Tuesday, July 15, 2025 at 12:55:58 AM UTC+8 Ian Lance Taylor wrote: On Sun, Jul 13, 2025 at 9:06 AM Qingwei Li <qingwe...@gmail.com> wrote: I notice that in cmd/internal/telemetry/counter/, there are counter.go and counter_bootstrap.go. They are different in the build tags. For counter.go, the build tag is "//go:build !cmd_go_bootstrap && !compiler_bootstrap". For counter_bootstrap.go, it is "//go:build cmd_go_bootstrap || compiler_bootstrap". counter_bootstrap.go does not import golang.org/x/telemetry/counter while counter.go does. After generate project in pkg/bootstrap/src/bootstrap directory, the command `GOROOT_BOOTSTRAP/bin/go install -tags="math_big_pure_go compiler_bootstrap purego" bootstrap/cmd/...` is executed. So to build toolchain1, actually counter_bootstrap.go is used and no vendor packages are imported. Thanks, I missed that. Since the bootstrap process works, and vendored packages are used in stages 2 and 3, what is the advantage of supporting vendored packages in stage 1? Ian -- 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 visit https://groups.google.com/d/msgid/golang-nuts/8b2b31d8-c716-43a8-8090-ed613427ef40n%40googlegroups.com.
