On Wed, 21 Nov 2018 at 01:32, Trevor Woerner trevor@toganlabs.com wrote:
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
tools/buildman/toolchain.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
BTW I really appreciate your great commit msg.
- Simon