All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Andrejs Cainikovs <andrejs.cainikovs@toradex.com>,
	Brandon Maier <brandon.maier@collins.com>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH v3 2/3] buildman: Allow skipping the dtc build
Date: Tue, 10 Sep 2024 12:52:37 -0600	[thread overview]
Message-ID: <20240910185237.GM4252@bill-the-cat> (raw)
In-Reply-To: <CAFLszTjfU8m-dQyXXAHJ0FWGfAMdvF3yYDMOofN87qocY0mRyg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5256 bytes --]

On Tue, Sep 10, 2024 at 12:45:39PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 10 Sept 2024 at 12:42, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Sep 10, 2024 at 12:41:11PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 2 Sept 2024 at 09:39, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sun, Sep 01, 2024 at 02:09:39PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 22 Aug 2024 at 08:10, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Aug 21, 2024 at 09:00:25PM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Fri, 16 Aug 2024 at 17:53, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Fri, 16 Aug 2024 at 11:22, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Aug 15, 2024 at 01:57:45PM -0600, Simon Glass wrote:
> > > > > > > > >
> > > > > > > > > > For most boards, the device-tree compiler is built in-tree, ignoring the
> > > > > > > > > > system version. Add a special option to skip this build. This can be
> > > > > > > > > > useful when the system dtc is up-to-date, as it speeds up the build.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > (no changes since v1)
> > > > > > > > > >
> > > > > > > > > >  tools/buildman/builder.py       | 27 ++++++++++++++++++++++++++-
> > > > > > > > > >  tools/buildman/builderthread.py |  4 ++--
> > > > > > > > > >  tools/buildman/buildman.rst     |  3 +++
> > > > > > > > > >  tools/buildman/cmdline.py       |  2 ++
> > > > > > > > > >  tools/buildman/control.py       |  3 ++-
> > > > > > > > > >  tools/buildman/test.py          | 31 +++++++++++++++++++++++++++++++
> > > > > > > > > >  6 files changed, 66 insertions(+), 4 deletions(-)
> > > > > > > > >
> > > > > > > > > We should probably do this more generically, outside of buildman. We
> > > > > > > > > have scripts/dtc-version.sh and if the system version isn't new enough
> > > > > > > > > (and we just need to define whatever the minimum version is), then we
> > > > > > > > > build our (not currently that new anymore) dtc instead.
> > > > > > > >
> > > > > > > > Yes I think I did a patch for that ages ago [1], but it was rejected.
> > > > > > > >
> > > > > > > > I'd be very happy for it to be applied as I think it is a better
> > > > > > > > solution than this one.
> > > > > > > >
> > > > > > > > I see that some poor sod tried to do this in Linux this morning.
> > > > > > >
> > > > > > > Any thoughts on that patch?
> > > > > >
> > > > > > I'm open to re-considering [1] again, but we need to handle the warning
> > > > > > problem first. That means...
> > > > > >
> > > > > > > Also I do see one problem. Newer dtc version produce a lot of
> > > > > > > warnings, which causes CI to fail. So if we always use the newest
> > > > > > > version, people are going to see a ton of warnings when they run
> > > > > > > locally. Am I missing something here?
> > > > > >
> > > > > > Well, it would be great to get our Kbuild logic anywhere close to
> > > > > > in-sync again with upstream. But syncing up the disabling warning flags
> > > > > > shouldn't be too hard.
> > > > >
> > > > > So, coming back to this patch, the nice thing about it is that it is
> > > > > deterministic. So people who build U-Boot and don't want funky
> > > > > behaviour will be happy. It will use the internal dtc by default. To
> > > > > use the external one, you must provide an option.
> > > > >
> > > > > This patch only affects buildman, but as you can see the mechanism it
> > > > > uses is to set the DTC variable, which people can do without buildman.
> > > > > It's just a convenience, but useful enough to have a flag, I believe.
> > > >
> > > > Wait, that's right, we have DTC as a thing that can be set in the
> > > > environment, so why do we need something for buildman at all?
> > >
> > > It's a convenience. I have found that it speeds things up quite a bit,
> > > so I want to enable it most of the time. But we can't do it by default
> > > and need it to be optional, I believe.
> >
> > I wasn't clear, sorry. Why is:
> > $ export DTC=/usr/local/bin/dtc
> > $ tools/buildman/buildman ...
> >
> > Enough?
> 
> My patch is more equivalent to:
> 
> DTC=`which dtc` buildman...
> 
> As I said it is a convenience which I want to use all the time,
> including in CI. Are you worried about changing buildman? What is the
> issue here?

My question / concern is why do we need:

>  6 files changed, 66 insertions(+), 4 deletions(-)

When we can do it with zero code changes? And then similar to the
worries I set aside with the "venv" related changes, you're making one
tool be clever and work as exactly as expected (but perhaps in a "do
what I meant, not what I said" manner?) way. If we have "set DTC in
environment, it's always obeyed, can be passed directly to make" but
also "pass buildman a flag to say where dtc is" why do we need the
latter if it should already be working, and I think already is working?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-09-10 18:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-15 19:57 [PATCH v3 0/3] This series adds a few patches to make it easy to use the system dtc in Simon Glass
2024-08-15 19:57 ` [PATCH v3 1/3] buildman: Support building within a Python venv Simon Glass
2024-09-06  0:53   ` Simon Glass
2024-08-15 19:57 ` [PATCH v3 2/3] buildman: Allow skipping the dtc build Simon Glass
2024-08-16 17:22   ` Tom Rini
2024-08-16 23:53     ` Simon Glass
2024-08-22  3:00       ` Simon Glass
2024-08-22 14:10         ` Tom Rini
2024-08-22 14:15           ` Simon Glass
2024-09-01 20:09           ` Simon Glass
2024-09-02 15:39             ` Tom Rini
2024-09-10 18:41               ` Simon Glass
2024-09-10 18:42                 ` Tom Rini
2024-09-10 18:45                   ` Simon Glass
2024-09-10 18:52                     ` Tom Rini [this message]
2024-09-10 20:14                       ` Simon Glass
2024-09-10 22:07                         ` Tom Rini
2024-09-12  1:01                           ` Simon Glass
2024-09-12 17:44                             ` Tom Rini
2024-09-19 14:13                               ` Simon Glass
2024-09-26 22:07                                 ` Simon Glass
2024-08-15 19:57 ` [PATCH v3 3/3] RFC: CI: Skip building dtc for world builds Simon Glass
2024-10-10 18:50   ` Simon Glass
2024-10-10 19:01     ` Tom Rini
2024-10-14 19:13       ` Simon Glass
2024-10-14 22:43         ` Tom Rini
2024-09-06 22:37 ` (subset) [PATCH v3 0/3] This series adds a few patches to make it easy to use the system dtc in Tom Rini

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=20240910185237.GM4252@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=andrejs.cainikovs@toradex.com \
    --cc=brandon.maier@collins.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.