Sorry, forgot the list...
Subject: Re: [cfe-dev] Small patches to allow fully independent
clang/llvm/compiler-rt/libc++
Date: Thu, 15 Oct 2015 14:50:11 +0200
From: Mario Werner <nioshd@gmail.com>
To: Renato Golin <renato.golin@linaro.org>Maybe I am wrong but isn't this whole approach really similar to the
cross compiler config files [1] which Richard Pennington proposed last year?
That proposal was based on our discussion derived from this model. 
It's one and the same.
If so it maybe possible to reuse his implementation from ellcc...
Yup. No reasons why not to.
But we shouldn't start on the driver, nor we should create something
that breaks compatibility with other compilers. Ellcc has no such
problem, so even if we are to merge his code, we'll have to adapt to a
more widely used compiler.
cheers,
--renato
Beyond the complicated things you plan to do with config files and
other stuff...
1) What should us humans do in the meantime? If it's not done in 30
days can we consider something simple which gets the job done?
2) Instead of having the compiler read a config file *every* time -
would it be possible to just compile that into the driver?
Implementation detail, but keep installs a bit less complicated.
For example - where would the config file live? /etc/clang ? What
happens if a config file is installed globally, but you don't want
your local built compiler to use it? (Can you turn it off or
statically compiler your preferred version in)
3) If someone who understands this proposal - would you confirm that
it will allow
clang foo.c # No flags or triples or tuples or gimples.. it just works
and magically underneath will be gnu-free
1) What should us humans do in the meantime? If it's not done in 30
days can we consider something simple which gets the job done?
I don't really know. This idea has at least 5 years (I proposed it in
2010) and has been in the list of projects for a while. Nobody seemed
to care much, so I just gave up until this week when someone was
interested in actually implementing it.
The first step would be to have a script that only calculates the
CFLAGS, like llvm-config, so:
$ clang `llvm-target-config --target=mips-linux-gnu --something else`
You can write that script yourself, or liaise with the other people
interested in it to speed up the process. That'd get the job done. I
don't recommend it on a product, or long term support. It's a hack.
2) Instead of having the compiler read a config file *every* time -
would it be possible to just compile that into the driver?
Implementation detail, but keep installs a bit less complicated.
Perfectly possible. My original idea was to have that in git anyway,
so no reason why Clang can't incorporate it into code (a la TableGen).
Future changes can be submitted as a patch to Clang. Plain and simple.
clang foo.c # No flags or triples or tuples or gimples.. it just works
and magically underneath will be gnu-free
If the script / Clang can detect the environment better than it does
today, it could realise that it wants to build a gnu-free binary just
by looking at the filesystem (/etc/release info, /usr/lib stuff,
/proc/cpuinfo vendor).
The names on the configuration database shouldn't change, but the way
they're recognised and set the default are clearly possible.
cheers,
--renato