kdev-clang

[René J.V. Bertin]

On Wednesday January 28 2015 12:25:11 Milian Wolff wrote:


> That's missing llvm-config as far as I can see. Do you even have a libclang.so 
> that provides the Clang C API? What about the headers - are they available?

Yes, llvm-config is missing, as I said :)

Not being sure what you need, how about a more or less complete listing of the Developer directory inside the Xcode bundle (i.e. excluding platform SDKs): https://paste.kde.org/pwa2qlzdy
If you can give me a few headerfile names, I can do a more specific search.

quoth kevin:
> Not having a llvm-config is an issue atm -- since we're using it to figure
> out the include and library dirs of LLVM/Clang.

True, but *if* the headers are shipped by Apple, they'll always be at the same place relative to the Xcode application. And as shown in my previous message, there's a call to determine the currently active toolchain.

> In fact, we cannot rely on Xcode being available
> anyway. You shouldn't have to install Xcode in order to compile kdev-clang,
> right.

Heh, go tell that to Apple. As a matter of fact, they do ship a command line version (which can also be queried with the xcode-select command), but that is lacking certain things aside (of course) the IDE. Trust me, there's very little margin to make do without Xcode if you want to do any kind of development or compiling on OS X, so little that it's a very safe assumption for any build system that Xcode will be present, and reasonable to make it a requirement. (All close to 6Gb of it :-/)

> I wouldn't waste time on using it. You are beating a dead horse here.
                                             ^ remove 1 letter and you'll have my full attention ;)

I was never planning on using it if it's that outdated. Just on figuring out how to get it to build against Apple's toolchain, which would be a good thing to have for the current version too. IMHO.

> that regard. Pure indexing of a project is, in my tests, considerably faster 
> now that we are smarter at handling headers and translation units. Whats still 
> a bit slow is code completion, but mostly because we didn't spent a good 
> amount of time investigating the performance there yet.

Is there any reason to think that those observations also (or don't) hold for low-end hardware? Just asking so I know if it's worth the hassle building the component on that same slow hardware (which could of course use any possible kind of performance gain).

R