when toolchain.conf was designed, there was only one overlay in a board's stack that would have a toolchain.conf. as we expanded the overlays, we could have more than one toolchain.conf, but they were generally just copies of each other rather than truly extending them (e.g. as we migrated content from private to public repos).
fast forwarding today, we're finding people adding toolchain.conf files to chipset, baseboard, and overlays with different content. this exposed a bug in our selection of the "default" tuple: while we walked the overlays in the correct order (from the parent to the child), we found that the default was always pulled from the first toolchain.conf file found. so if we had one in the chipset, one in the baseboard, and one in the overlay, the chipset would set the default.
this was not the intention ... the default should be taken from the "final most" overlay, not from the first one found in the stack (the "lowest" one).
as part of this fix, we find that people have been adding toolchain.conf files that break this logic as well: the chipset will define the default (e.g. x86_64), then the baseboard will stack on top of that but only add what is needed (e.g. arm for an EC), and the final overlay wouldn't do anything.
we'll need to clean this up and then fix the toolchain.conf parsing.
Comment 1 by vapier@chromium.org
, Jul 28here's the script i'm running to make sure all my changes don't cause regressions: # Find all relevant boards. $ cd ~/chromiumos/src $ set -- `awk '$1 == "repo-name" { print $NF }' *overlays*/overlay-*/metadata/layout.conf | sed 's:-private$::' | sort -u` # Output the final toolchain.conf settings. $ python -c $'from chromite.lib import toolchain; import sys;\nfor b in sys.argv[1:]:\n print(b, toolchain.GetToolchainsForBoard(b))' "$@" then i save the output and re-run it after each series of CLs.