port:libclang (and libLLVM)

[Chris Jones]

> On 9 Mar 2016, at 5:08 pm, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
>> On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote:
>> 
>> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50
>> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather
>> than 3.4+ GB.
> 
> I use a patched portimage.tcl that uses bsdtar from port:libarchive which supports the --hfsCompression argument. I know the gain can be significant, but never calculated it precisely.
> 
> Regardless, >700Mb is still a far cry from (>10x) what I've seen cited for just libclang.
> 
>> One potential port that comes to mind would be cling
>> as dependency of (= part of) ROOT 6, but I would imagine that it would
>> need quite a bit of effort before ROOT and/or cling could simply
>> depend on "libclang"
> 
> Looks like "Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries" but is built inside *a* llvm+clang tree hosted by the CERN and having a dedicated branch called cling-patches. That does seem to make it a bit unlikely that one day cling could build against a stock libclang ...

Well, that is true but i also know that the root team always looks to push as much as it can upstream, and very much work with the clang developers. So, yes, at the moment there are a number of patches applied, but that doesn't mean at some point in the future they would be removed. But i think the root team have a number of much more pressing things to fix first (like gcc 5 support. Currently on linux clang cannot be built and run against the gcc5 abi), and ultimately the root team might decide they only wish to support build their own internal clang version, for various reasons (the one you mention below for instance being one.)

> 
> Another potential candidate for which I already have a personal port is clazy: https://www.kdab.com/use-static-analysis-improve-performance/
> 
> 
> About libLLVM: I'm told that libclang's dependency on libLLVM happens "when you build enable shared libraries for libLLVM. This is not good for performance, and should not be done when you want to create a libclang for redistribution purposes."
> 
> I've heard that before, and wonder if it's the reason clang-mp-x.y has always been up to 2x slower than equivalent Apple builds (and not just for me).
> 
> Is there a reason the LLVM ports build a shared libLLVM?
> 
> R.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev