[KDE/Mac] Creating a OS X packaging receipt for DMGs?

[René J.V. Bertin]

On Wednesday March 09 2016 13:10:39 Milian Wolff wrote:

>Note again: We do not depend on LLVM or Clang in KDevelop. We only require 
>libclang, the C API of clang, and yes - that is something different!

But it's built as part of clang (and libllvm as part of llvm), no?

>Have you tried linking against that libclang? Is XCode also shipping the 

No, because I haven't yet dared to hack together my own llvm-config, or worse, combine Xcode's libclang with an otherwise unrelated llvm.

>development headers? On Linux they are in /usr/include/clang-c, look for 
>Index.h. I'm also interested in the values of the `CINDEX_VERSION_*` macros 
>included therein.

Not that I was really expecting it, but damn, no. No Index.h, nor any .h file containing CINDEX_VERSION. 
At least now we know ...

>> There should be no drawbacks to such an approach if the library can be
>> embedded (nor for people who build against shared resources like I do).
>
>This is contradictory, or I'm not following your train of thought. The above 
>makes me believe you want to link against XCode's libclang, i.e. explicitly 
>_not_ embed the library with KDevelop?

Probably moot now, but if libclang is standalone it should be possible to embed it. The libclang.dylib from my Xcode is built to live at "@rpath/libclang.dylib" meaning that the dynamic linker will find it anywhere on the application's rpath.

>The Clang library has a C API with stable ABI. Thus linking against the 
>minimum supported XCode that fulfills our requirements should be enough. Any 
>later versions should then work as well. I.e. there is no need to support 
>builds for various XCode versions.

There are no feature evolutions in the API that you can support when you detect them?

>That sounds like you did not disable assertions while building Clang.

No, they're supposed to be disabled in the release version of the packages I'm using (the packaging scripts seem to confirm that).
I think your hypothesis about the influence of using a shared libLLVM is more relevant, though I can hardly imagine that in this case the use of a shared library causes such a significant overhead where in other applications that overhead is (supposed to be) negligible.

Cheers,
R.