]> git.baikalelectronics.ru Git - uboot.git/commit
buildman/toolchain.py: fix toolchain directory
authorTrevor Woerner <trevor@toganlabs.com>
Wed, 21 Nov 2018 08:31:12 +0000 (03:31 -0500)
committerSimon Glass <sjg@chromium.org>
Wed, 5 Dec 2018 13:01:35 +0000 (06:01 -0700)
commit065e5b3ccfde9e3b75a991d545c0f7798164528f
tree15b85d415149cf7cd7f6a5af1947e4c03944a257
parentb7115834de661e8c1e01ddce4eea8451fe75e19d
buildman/toolchain.py: fix toolchain directory

The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
a way that is different from most toolchains. The first entry when unpacking
most toolchain tarballs is:

gcc-<version>-nolib/<targetarch>-<system>

e.g.:

gcc-8.1.0-nolibc/aarch64-linux/

The first entry of the hexagon toolchain, however, is:

gcc-4.6.1-nolibc/

This causes the buildman logic in toolchain.py::ScanPath() to not be able to
find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
tries to download a set of toolchains that includes hexagon, the script fails.

This update takes the second line of the tarball unpacking (which works for
all the toolchains I've tested from kernel.org) and parses it to take the
first two elements, separated by '/'. It makes this logic a bit more robust.

Signed-off-by: Trevor Woerner <trevor@toganlabs.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
tools/buildman/toolchain.py