Fuse the two halves of the GCC installation detection. This is
significantly cleaner (IMO) and more principled. We now walk down each layer of the directory hierarchy searching for the GCC install. This change does in fact introduce a significant behavior change in theory, although in practice I don't know of any distro that will be impacted by it negatively, and Debian may (untested) get slightly better through it. Specifically, the logic now looks exhaustively for patterns such as: /usr/lib/<triple>/gcc/<triple> Previously, this would only be selected if there was *also* a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat DefaultHostTriple in the driver. There is a 4-deep nested loop here, but it doesn't do terribly many filesystem operations, as we skip at each layer of that layer's directory doesn't exist. There remains a significant FIXME in this logic: it would be much better to first build up a set of candidate components for each of the four layers with a bottom-up pruning such as this, but then select the final installation using a top-down algorithm in order to find the newest GCC installation available, regardless of which particular path leads to it. llvm-svn: 141071
Loading
Please register or sign in to comment