Toolchains

[GPMueller]

After merging PR #118, which introduces the toolchain module, we should consider the following long-term goals for what a toolchain should be.

A toolchain should provide

• the build platform (on which clang-build is being run), e.g.
  • windows
  • osx
  • linux
• the host platform (on which the build results may be run), e.g.
  • windows
  • osx
  • linux
  • web / browser
• the host architecture (on which to run the built binaries), e.g.
  • x86
  • GPU
  • web / wasm
• a list of supported C-dialect languages, e.g.
  • C
  • C++
  • CUDA-C
  • CUDA-C++
  • OpenCL
  • Objective-C
  • Objective-C++
• default compile and link flags for all target types (executable, ...) for all build types (debug, ...) for the available languages for the given combination of build and host platform

One toolchain should support only one host platform and architecture per build platform. Alternatively we might even split the toolchains by build platform (i.e. llvm on windows is a different toolchain from llvm on linux).

Toolchain Selection

We need to provide some mechanism for toolchain selection. A simple command line flag would be enough, e.g. clang-build --toolchain=/path/to/toolchain.py. However, we also need to decide how this API should work - should the toolchain.py provide a get_toolchain function, analogous to the get_project function that is the API for clang-build.py project files?

Examples we could try to get running

1. from <OS>, compile C++ for x86 on <OS> (llvm toolchain)
2. from <OS>, compile CUDA-C++ for GPU on <OS> (llvm toolchain)
3. from <OS>, compile C++ for wasm on web (emscripten toolchain)

[GPMueller]

The basic toolchain module has been merged with 97367e088b6f59b11708ee5e7099e9f37c99d510.

[GPMueller]

The Emscripten toolchain has been merged with 0f5970adebc86b40d74926a926d5dcfc6bcb421f. Improvement of the class structure will be tracked on issue #137.