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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
