| 1 | | Currently the logic in the cctools port that picks the clang version to use with `as` is tied to the llvm version used to build the port, via the variant. This is a reasonable enough way to do it, but technically is not required. Instead of hardcoding into the as binary the MP clang version matching the llvm variant, we *could* pass in a list of all possible reasonable versions, starting with the most recent and working back. i.e. the list of all possible llvm variant versions. `as` would then start at the beginning of this list and use which either it first finds.... This would allow the port to still be built using the llvm 3.x version, but still when as is used at runtime pick a more recent clang version. |
| | 1 | Currently the logic in the `cctools` port that picks the clang version to use with `as` is tied to the llvm version used to build the port, via the variant. This is a reasonable enough way to do it, but technically is not required. Instead of hardcoding into the as binary the MP clang version matching the llvm variant, we *could* pass in a list of all possible reasonable versions, starting with the most recent and working back. i.e. the list of all possible llvm variant versions. `as` would then start at the beginning of this list and use which either it first finds.... This would allow the port to still be built using the llvm 3.x version, but still when `as` is used at runtime pick a more recent clang version. |
