[PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Vasileios Kalintiris via cfe-commits]

vkalintiris added inline comments.

================
Comment at: lib/Driver/Driver.cpp:2225
@@ -2219,1 +2224,3 @@
         TC = new toolchains::HexagonToolChain(*this, Target, Args);
+      else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
+               !Target.hasEnvironment())
----------------
atanasyan wrote:
> Now I try to redesign Codescape toolchain support in the Clang driver. I consider to use a separate toolchain class like your `MipsToolChain` and I name it `CodeScapeMtiToolChain`. If I be able to join support for both MIT and IMG toolchains in the single class, I will rename it to `CodeScapeToolChain`.
> 
> Will this non-GNU toolchain have a personal name like CodeScape? If not I am okay with `MipsNonGNUToolChain`.
I thought about this and I don't believe that `MipsNonGNUToolChain` is a very good name. The main reason is that the last component of the entries under the sysroot, contain the name of the C library (or empty for GLIBC). We could easily have a toolchain with `mips-r2-hard{,-uClibc}` installed for `mips-mti-linux`.

What are your thoughts about the names: `MipsGCCToolChain`, `Mips{Clang,LLVM}ToolChain`, or `CodescapeGCCToolChain` and `CodescapeLLVMToolChain`?

Personally, I'd prefer the first pair of names. The reason is that with this choice we will be consistent in the naming of our classes. Also, it's clear that these are MIPS TCs and we have to consider that the Codescape name could change in the future (improbable but not impossible).

The `Mips{GCC,Clang/LLVM}Toolchain` name would specify whether we are going to use the files generated from a GCC or Clang installation. This way we could keep the existing functionality of the `Linux` class for older toolchains that will be deprecated/unused over time.


http://reviews.llvm.org/D13340