Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Christian Stewart <christian@paral.in>
Cc: "Yann E . MORIN" <yann.morin.1998@free.fr>,
	Christian Stewart via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH v3 1/3] package/go-bootstrap: split into two stages: go1.4 and go1.19.5
Date: Fri, 31 Mar 2023 12:24:08 +0200	[thread overview]
Message-ID: <20230331122408.211f7639@windsurf> (raw)
In-Reply-To: <CA+h8R2ppxhXNkWSO9qWar2d21Xg7cWzZ8nJR82PyBF4=5+bpfQ@mail.gmail.com>

On Thu, 23 Mar 2023 19:45:04 -0700
Christian Stewart <christian@paral.in> wrote:

> > This doesn't make much sense. Why would the toolchain package be needed
> > for HOSTCC_NOCCACHE ? We have several packages that use HOSTCC_NOCCACHE
> > before the toolchain is ready.  
> 
> I suppose HOSTCC_NOCCACHE uses the gcc installed outside of buildroot,
> so it should be fine to remove this dependency.

Yes, the native toolchain must always be provided by the system, it is
not provided by Buildroot. The "toolchain" package only provides the
cross-compilation toolchain, it does nothing about the native toolchain.

> > > +     # Set all file timestamps to prevent the go compiler from rebuilding any
> > > +     # built in packages when programs are built.
> > > +     find $(HOST_GO_BOOTSTRAP_STAGE2_ROOT) -type f -exec touch -r $(@D)/bin/go {} \;  
> >
> > So we have to do this for bootstrap-stage2 but not bootstrap-stage1 ?  
> 
> It's not strictly necessary for either one. I removed it for the next
> revision of the patch.

But your comment above seemed to indicate that it was necessary.

> > > -     depends on BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS
> > > +     depends on BR2_PACKAGE_HOST_GO_BOOTSTRAP_STAGE2_ARCH_SUPPORTS
> > > +     # See https://go.dev/doc/install/source#environment
> > > +     # See src/go/build/syslist.go for the list of supported architectures  
> >
> > This comment looks good, but is unrelated. Separate patch?  
> 
> Is it really necessary to put in a separate patch? It's a minor comment change.
> 
> Feels appropriate to bundle it here with other related changes.

Well, it always makes the review a bit more complicated, as we wonder
why it's there. If you really want to bundle unrelated changes like
this, they should at least be mentioned in the commit log so that the
reviewer knows what's going on.


> > > -# The go build system is not compatible with ccache, so use
> > > -# HOSTCC_NOCCACHE.  See https://github.com/golang/go/issues/11685.
> > > +# The go build system is not compatable with ccache, so use HOSTCC_NOCCACHE.
> > > +# See https://github.com/golang/go/issues/11685.  
> >
> > Why is this comment being changed, with a typo added?  
> 
> Fixed the typo. The comment is being changed because it can fit on a
> single line in 75 characters.
> 
> It just looks cleaner.
> 
> I can revert this if necessary.

Same as above: it's creating some unrelated "noise" in the patch, which
makes things odd when doing a review.

> 
> > >  HOST_GO_MAKE_ENV = \
> > >       GO111MODULE=off \
> > >       GOCACHE=$(HOST_GO_HOST_CACHE) \
> > > -     GOROOT_BOOTSTRAP=$(HOST_GO_BOOTSTRAP_ROOT) \
> > > +     GOROOT_BOOTSTRAP=$(HOST_GO_BOOTSTRAP_STAGE2_ROOT) \
> > >       GOROOT_FINAL=$(HOST_GO_ROOT) \
> > >       GOROOT="$(@D)" \
> > >       GOBIN="$(@D)/bin" \
> > > @@ -154,7 +154,6 @@ define HOST_GO_INSTALL_CMDS
> > >       cp -a $(@D)/pkg/include $(@D)/pkg/linux_* $(HOST_GO_ROOT)/pkg/
> > >       cp -a $(@D)/pkg/tool $(HOST_GO_ROOT)/pkg/
> > >
> > > -     # There is a known issue which requires the go sources to be installed  
> >
> > Why is this comment being removed?  
> 
> It's not an issue, per se. The nature of the Go compiler is that it
> needs the sources to work.
> That bug report has been closed for years now and is actually
> unrelated to needing sources anyway.

So perhaps rephrase to explain "Yes the Go compiler needs the sources
to work", rather than just dropping the comment? But here again, it's
unrelated to the patch we're discussing so => separate patch.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-03-31 10:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15  7:32 [Buildroot] [PATCH v3 1/3] package/go-bootstrap: split into two stages: go1.4 and go1.19.5 Christian Stewart via buildroot
2023-02-15  7:32 ` [Buildroot] [PATCH v3 2/3] package/go: bump to version 1.20.1 Christian Stewart via buildroot
2023-02-15  7:32 ` [Buildroot] [PATCH v3 3/3] package/go: use host compiler when go-bootstrap unsupported Christian Stewart via buildroot
2023-03-12 22:04   ` Thomas Petazzoni via buildroot
2023-03-12 21:58 ` [Buildroot] [PATCH v3 1/3] package/go-bootstrap: split into two stages: go1.4 and go1.19.5 Thomas Petazzoni via buildroot
2023-03-24  2:45   ` Christian Stewart via buildroot
2023-03-31 10:24     ` Thomas Petazzoni via buildroot [this message]
2023-03-25 13:34 ` Bagas Sanjaya
2023-03-25 13:39   ` Bagas Sanjaya
2023-03-25 16:54   ` Christian Stewart via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230331122408.211f7639@windsurf \
    --to=buildroot@buildroot.org \
    --cc=christian@paral.in \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox