[cfe-dev] Clang Configuration Manager

[Renato Golin via cfe-dev]

On 12 October 2015 at 01:35, Cornel Punga via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> I want to work on Configuration Manager open project.

Hi Cornel,

I wrote that spec, so I'll try to give you an overview of what I
meant. That doesn't mean you have to do exactly that, just to guide
you on your implementation.


> In the description of the project (here) the first step would be to build a
> CFLAGS file. I think it is something similar to the Makefile in the root
> directory of the Clang, is that right?

No. The idea was to do something similar to "llvm-config", but the
other way around.

The llvm-config tool, like similar ones, gives you a way to collect
the flags needed to compile an LLVM based project. What this first
step would be is to do the same for the hardware.

GCC's structure is largely based on configure-time hard-coded values.
So, from the same source, you can build a cross-compiler from
virtually any host to any target, and the defaults and options will be
restricted to the target arch. LLVM doesn't work like that.

When you build LLVM, you build everything. You can cross-compile from
one host to any target (if you compile all back-ends) on the same
binary. Because of that, some options get slightly different
behaviour, or they're only valid for one or another back-end, or they
need another options to be set and correct, otherwise things blow up
badly.

So, there are two side of stage 1:

1. Identify the host architecture (system introspection), and present
the best combination of flags (mcpu, mfpu, march, etc) to produce the
fastest code on the *host*. This will detect the CPU, SIMD,
co-processors, variations and choose the right options.

2. Identify the target, when host != target. This is more complicated,
since however you detect it will depend on the target. If the target
has an OS, you can telnet/ssh into it and query the system, but some
OSs will need a server running on the target (Windows?). If the target
is bare-metal, you'll need some JTAG equivalent, and thus interface
with drivers on the host system.

This second part would be more of a large collection of tools, rather
than one single script.

The second stage is to put these scripts into a local database (a JSON
file would be enough), so that you could choose via Clang
-mconfig=target-name and it'd automatically detect and pull the config
from inside Clang. The scripts would still be used to create the
database, though.


> And the last, for now, would Python be a suitable choice for this project or
> better write it in C++?

Python would be perfect.

cheers,
--renato