Were you at the driver BoF at the conference? We discussed the cross compilation story there (although your solution does look similar to that discussed, so maybe that's not a coincidence...)
Yes I have attended the BoF on the driver.
I'm actually already working on a patch to do the same. I think the problem is more involved than just setting up target and include dirs - I think the target database should have OS specific information too (which flags are required per OS etc, so a distro maintainer can change whatever he may need at package time without patching the source).
As I say, I'm working on a patch that I think is a superset of yours and would conflict massively. I've been planning it for some time and think I have a viable end goal and route to get there. Would it be possible for you to hold off your patch for a week or so until mine is ready and can be used as a base?
That's fine with me.
Don't get me wrong, using a configuration file would allow us to kick
out all the nasty Linux logic. It just doesn't make sense for platforms
with a sane layout.
Exactly! That's the bug that bite me!
Especially after the refactoring that went in the last minute in the
llvm 3.0 branch...
that was actually a backport of several changes that are currently in tot.
To fix this we would have to completely disable the detection of native
system headers when the c-include-dirs has been specified, either at
configure time, or in a target config file.
Ideally, yes! I'd love for it to be a case of autodetecting the linux distro and then from that being able to infer without any further tests where the headers should be (relative to sysroot).
Not to nitpick but as a stickler for clear English should not the following read as:
You missed that discussion by about 15 years.