From: Trent Piepho <trent.piepho@igorinstitute.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: Barebox List <barebox@lists.infradead.org>,
ejo@pengutronix.de, rhi@pengutronix.de, uol@pengutronix.de,
renaud.barbier@abaco.com
Subject: Re: [PATCH 3/4] scripts: unify libusb.h inclusion
Date: Tue, 14 Sep 2021 12:22:25 -0700 [thread overview]
Message-ID: <CAMHeXxMyGYAM=TSE=V9h8jnkO8rmDE-e5axKeCwURvqcYoG63A@mail.gmail.com> (raw)
In-Reply-To: <20210914132016.22572-3-a.fatoum@pengutronix.de>
On Tue, Sep 14, 2021 at 6:21 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> I've also run into downstream patches around broken toolchains that
> change <libusb.h> to <libusb-1.0/libusb.h>, so the header is found.
How does this become a problem exactly? If the toolchain has the file
in the location <includedir>/ibusb-1.0/libusb.h, then shouldn't
pkg-config --cflags have returned -I<includedir>/libusb-1.0 and it
would then find the file just fine?
Or is the problem really that the cross building setup does not have
correct .pc files?
If it's the latter, then I'll point out that my previous email would
let someone put CROSS_LIBUSB_CFLAGS=-I<cross-include-dir>/libusb-1.0
on the make command line and get a build without having .pc files.
This is pretty much what you get with autoconf configure scripts when
you put headers in a non-standard place and don't have .pc files setup
to find them. You need to supply CFLAGS, LDFLAGS, etc. variables with
the proper -L and -I options to find them.
> +++ b/scripts/libusb.h
By naming this libusb.h, it requires that "libusb.h" find this file
and <libusb.h> find a different header of the same name. That's
certainly possible by being careful with the "" and <> search paths.
But it seems unnecessarily fragile. I suggest using libusb-wrapper.h
for this file so you avoid name collisions with the real header file.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2021-09-14 19:24 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 [this message]
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
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:
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='CAMHeXxMyGYAM=TSE=V9h8jnkO8rmDE-e5axKeCwURvqcYoG63A@mail.gmail.com' \
--to=trent.piepho@igorinstitute.com \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=ejo@pengutronix.de \
--cc=renaud.barbier@abaco.com \
--cc=rhi@pengutronix.de \
--cc=uol@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox