mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <>
To: Ahmad Fatoum <>
Cc: Barebox List <>,,,,
Subject: Re: [PATCH 4/4] scripts: allow building USB loader tools for target as well
Date: Wed, 15 Sep 2021 02:38:36 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Sep 15, 2021 at 1:50 AM Ahmad Fatoum <> wrote:
> On 14.09.21 21:11, Trent Piepho wrote:
> > On Tue, Sep 14, 2021 at 6:21 AM Ahmad Fatoum <> wrote:
> >>
> >> Users can override it as necessary, for example, with Yocto, pkg-config
> >> will be for the cross environment, so target tools can now be built
> >> with:
> >
> > I just added support to Buildroot for building imx-usb-loader from
> > Barebox, since it's nicer than the standalone version of the program.
> >
> > Since pkgconfig was only used for host tools, I didn't need to make
> > both host and target pkgconfig work.  But of course that will no
> > longer be true after this patch.
> It still wouldn't break your workflow, imx-usb-loader wasn't built
> for target so far.

But it wouldn't work for anyone who wanted both the host and target versions.

> > There is a problem with only supplying CROSS_PKG_CONFIG.  To get both
> > host and target pkgconfig to work, I also need to supply the env
> > variables used by pkgconfig, PKG_CONFIG_SYSROOT and PKG_CONFIG_LIBDIR.
> You can set these on the environment before starting barebox build.
> If you have a $(CROSS_COMPILE)pkg-config that doesn't need any further
> configuration, you can use that.

The problem is they need different values for the target and for the
host version of the package config.  The way you have done this it is
only possible for there to be one value that is used both when the
host version is called and the same values when the cross pkg-config
is called.

> > The former makes the paths returned by pkgconfig correct and the
> > latter controls which set, target or host, of .pc files will be used.
> >
> > Maybe something like this in the Makefile:
> >
> >
> > HOST_LIBUSB_CFLAGS := $(shell $(PKG_CONFIG) --cflags)
> > $(CROSS_PKG_CONFIG) --cflags)
> >
> > Then use those everywhere someone wants the libusb cflags.  Repeat for LDFLAGS.
> I am not really sold on this. Linux doesn't mess with PKG_CONFIG_ variables
> either. For perf the assume $(CROSS_COMPILE)pkg-config to be available.
> I think it's a suitbale default for us too. The lines above can go into
> a shell script wrapper.

Linux allows you to build the tools individually,  e.g. for tmon we have this:

make -C $(LINUX_DIR)/tools CC=$(TARGET_CC)
PKG_CONFIG_PATH=$(STAGING_DIR)/usr/lib/pkgconfig tmon

Can Barebox build do this?  This way there are multiple make calls,
with different options, to build a kernel for the target, dtc for the
host, tmon for the target, and so on.

So Linux build may not be an ideal pattern to copy.  It can not build
a tool for both host and target in one build.

> > You'll get fewer repeated invocations of pkg-config this way too.
> Ye, I thought about that as well, but we do it like this for the host tools,
> so I left it for now. It's not much overhead and it makes it a bit easier
> to follow what is used.

It looks like Linux build assigns pkg-config output to a variable in
every instance but dtc's build.  I think the existing Barebox
makefiles are just a bit sloppy in how they call pkg-config.

barebox mailing list

  reply	other threads:[~2021-09-15  9:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 13:20 [PATCH 1/4] common: remove !SANDBOX dependency for target tools Ahmad Fatoum
2021-09-14 13:20 ` [PATCH 2/4] common: add new menu " Ahmad Fatoum
2021-09-14 16:00   ` Roland Hieber
2021-09-14 13:20 ` [PATCH 3/4] scripts: unify libusb.h inclusion Ahmad Fatoum
2021-09-14 19:22   ` Trent Piepho
2021-09-15  8:55     ` Ahmad Fatoum
2021-09-14 13:20 ` [PATCH 4/4] scripts: allow building USB loader tools for target as well Ahmad Fatoum
2021-09-14 19:11   ` Trent Piepho
2021-09-15  8:50     ` Ahmad Fatoum
2021-09-15  9:38       ` Trent Piepho [this message]
2021-09-15 10:23         ` Ahmad Fatoum
2021-09-15  8:44   ` Enrico Jörns

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \

* 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