From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 8/8] buildman: Add a way to specific a full toolchain prefix
Date: Mon, 7 Mar 2016 14:08:06 -0700 [thread overview]
Message-ID: <56DDEDB6.2070202@wwwdotorg.org> (raw)
In-Reply-To: <1457318739-22993-8-git-send-email-sjg@chromium.org>
On 03/06/2016 07:45 PM, Simon Glass wrote:
> At present buildman allows you to specify the directory containing the
> toolchain, but not the actual toolchain prefix. If there are multiple
> toolchains in a single directory, this can be inconvenient.
>
> Add a new 'toolchain-prefix' setting to the settings file, which allows
> the full prefix (or path to the C compiler) to be specified.
>
> Update the documentation to match.
Since these are explicit requests, it would be nice if there was an
obvious failure if the requested toolchain was not found, rather than
just falling back to the existing search behaviour. For example, I
expected the following to work:
[toolchain-prefix]
arm: arm-none-eabi-
... but that was silently ignored. Instead I needed to write:
[toolchain-prefix]
arm: /usr/bin/arm-none-eabi-
Aside from that this patch works for me. I was rather hoping for a
cmdline or environment override, but I guess that feeling is influenced
by needing to change CROSS_COMPILE when switching between architectures;
with ~/.buildman I don't need that, so setting it up once in a file
should be OK.
When I tested this I wanted to make sure the request had been honored. I
tried telling buildman not to hide the build output, but the following
still prints almost nothing:
./tools/buildman/buildman -c 1 -T 1 -v -V p2371-2180
According to "buildman --help", that should print the full make output.
I also looked in the buildman work tree to see if the request had been
honored, at file
../.bm-work/00/build/arch/arm/mach-tegra/.cmd_enterrcm.o.cmd. That
looked fine, although ~/.buildman specified /usr/bin/aarch64-linux-gnu-
as the prefix whereas the command in that .o.cmd file was just
"aarch64-linux-gnu-gcc" without the path. It looks like buildman or
Kbuild is stripping off the leading path elements because /usr/bin is in
the $PATH. Is that expected?
next prev parent reply other threads:[~2016-03-07 21:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 2:45 [U-Boot] [PATCH 1/8] fdtgrep: Improve error handling with invalid device tree Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 2/8] patman: Add a missing space in GetMetaDataForList() Simon Glass
2016-03-07 16:43 ` Joe Hershberger
2016-03-13 1:51 ` Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 3/8] buildman: patman: Fix -H when installed as a symlink Simon Glass
2016-03-07 16:44 ` Joe Hershberger
2016-03-13 1:51 ` Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 4/8] buildman: Fix up a few code inconsistencies in toolchain.py Simon Glass
2016-03-07 16:45 ` Joe Hershberger
2016-03-13 1:51 ` Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 5/8] buildman: Allow branch names which conflict with directories Simon Glass
2016-03-07 16:46 ` Joe Hershberger
2016-03-07 2:45 ` [U-Boot] [PATCH 6/8] buildman: Allow the toolchain priority to be specified Simon Glass
2016-03-07 16:50 ` Joe Hershberger
2016-03-13 1:52 ` Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 7/8] buildman: Allow the toolchain architecture " Simon Glass
2016-03-07 16:58 ` Joe Hershberger
2016-03-13 1:52 ` Simon Glass
2016-03-07 2:45 ` [U-Boot] [PATCH 8/8] buildman: Add a way to specific a full toolchain prefix Simon Glass
2016-03-07 16:59 ` Joe Hershberger
2016-03-07 21:08 ` Stephen Warren [this message]
2016-03-13 1:50 ` Simon Glass
2016-03-07 3:07 ` [U-Boot] [PATCH 1/8] fdtgrep: Improve error handling with invalid device tree Masahiro Yamada
2016-03-07 3:31 ` Simon Glass
2016-03-07 16:37 ` Masahiro Yamada
2016-03-07 16:42 ` Joe Hershberger
2016-03-07 18:26 ` Simon Glass
2016-03-13 1:51 ` Simon Glass
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=56DDEDB6.2070202@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.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