UPDATE: The latest update to the configuration info is described here.

Today I decided to play around with some ideas for making clang a little more friendly for cross compiling. I added the ability to make the -target option look for and read in a configuration file if one is available. I build and use clang for cross compiling stuff. Up until now I’ve been using makefile magic to differentiate between different processor families and architectures. The original idea came from this mailing list post.

The thought behind my prototype is this: If a -target option is specified, or the clang executable name has a prefix (e.g. cortex-m4-ecc, ecc is my name for clang), then attempt to read a config file from the resource directory with the name of the -target argument or the executable prefix.

The config file would then be used to set things up to compile for a particular target.
Here is an example config file:

compiler:
  options:
    - -target arm-ellcc-linux-eabi5
    - -mcpu=cortex-m4
assembler:
  exe: $E/arm-elf-as
  options:
linker:
  exe: $E/ecc-ld
  options:
    - -m armelf_linux_eabi
    - --build-id
    - --hash-style=gnu
    - --eh-frame-hdr

  static_crt1: $R/lib/arm/linux/crt1.o
  dynamic_crt1: $R/lib/arm/linux/Scrt1.o
  crtbegin: $R/lib/arm/linux/crtbegin.o
  crtend: $R/lib/arm/linux/crtend.o
  library_path: $R/lib/arm/linux

I implemented the prototype this weekend, I like the way it feels. I created a CompilationInfo class that is passed to the Driver if a config file is used. I use the class in Tools.cpp if it is available to configure the assembler and linker invocations. Cool stuff.
This week I’ll use it to build libraries and programs for a variety of ARM variants. I’d also like to think about specifying #include file paths in the config file this week.

A few more details on the implementation so far. I use the -target argument, or the prefix on the compiler name, to try to open the config file. If a file of that name isn’t found, the -target argument passes through unscathed and works as it does now. I use YAMLIO to read the configuration into a structure that currently looks like this:

  typedef std::vector StrSequence;
  struct Compiler {
    StrSequence options;
  };

  struct Assembler {
    std::string exe;
    StrSequence options;
  };

  struct Linker {
    std::string exe;
    StrSequence options;
    std::string static_crt1;
    std::string dynamic_crt1;
    std::string crtbegin;
    std::string crtend;
    std::string library_path;
  };

  struct CompilationInfo {
    Compiler compiler;
    Assembler assembler;
    Linker linker;
  };

After some good discussion on the LLVM mailing list, I realized that with a simple registration process, statically initialized info structures could be registered by preexisting drivers. This would obviously eliminate the need to read the config file for every compilation.

Does this sound like a reasonable approach?