| 1 |
Hi Fabian, |
| 2 |
|
| 3 |
On Sun, Sep 04, 2016 at 05:06:56PM +0200, Fabian Groffen wrote: |
| 4 |
|
| 5 |
> I've patched the function to return / in case xcodebuild returns nothing |
| 6 |
> useful, such that we fall back to /usr/include, which makes the whole |
| 7 |
> thing compile for me. |
| 8 |
|
| 9 |
Well, I'd like to stress again that having Command Line Tools selected |
| 10 |
as the currently selected Xcode does not seem to be supported by the |
| 11 |
llvm cmake build system in Apple mode. As far as it's concerned someone |
| 12 |
building llvm needs to have a proper Xcode selected using xcode-select |
| 13 |
-s so it can find the SDKs within it. |
| 14 |
|
| 15 |
Is it actually possible to have only Command Line Tools installed |
| 16 |
(without Xcode) and get stuff to compile? I'm quite sure it was not in |
| 17 |
the olden days (<= 10.6). |
| 18 |
|
| 19 |
Also, I don't understand why there's a separate instance of the Command |
| 20 |
Line Tools somewhere in /Library and how it happens to be the default |
| 21 |
"Xcode" for some/most people. And also2, I don't understand why |
| 22 |
xcode-select even accepts it as a parameter for -s. This is all very |
| 23 |
weird. |
| 24 |
|
| 25 |
Anyway, I thought of your solution as well while paddling along the |
| 26 |
Peene. :) But on second thought I was wondering if we shouldn't patch |
| 27 |
any SDK selection and osx-min-version/OSX_DEPLOYMENT_TARGET for the host |
| 28 |
system (!) out of llvm/clang for prefix altogether. Prefix is always |
| 29 |
meant for the host system, right? Without any of this selection stuff, |
| 30 |
the compiler will fall back to the default include paths like |
| 31 |
/usr/include anyways and we eliminate a whole lot of possible grief in |
| 32 |
the future. IIRC I did this for 3.4.2 for exactly that reason but that |
| 33 |
got lost on the move to cmake some time around 3.7, I think. |
| 34 |
|
| 35 |
The only place I can think of where we'd need SDKs in the context of |
| 36 |
prefix is if we wanted to provide a fully cross-capable Apple-like |
| 37 |
toolchain for iOS and WatchOS and stuff like that. While binutils-apple |
| 38 |
should be able to provide that I guess no-one's ever even tested or |
| 39 |
played with it in that direction. And again, we'd need a proper Xcode |
| 40 |
installed and selected to find and use the proper SDKs for that. Full |
| 41 |
circle... |
| 42 |
-- |
| 43 |
Thanks, Micha |
| 44 |
Ich mag Kaba! |
Archives