port:libclang (and libLLVM)

[Jack Howarth]

On Wed, Mar 9, 2016 at 12:08 PM, René J.V. <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 ...
>
> 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).

Have you checked to make sure that the installed llvm packages aren't
built as the +assertions variant? The use of assertions will have a
large performance impact and isn't recommended for the llvm releases.
The llvm-3.8 Portfile was defaulting to the +assertions variant until
4 days back and only switched that off upon the official release of
3.8.0. However, port isn't smart enough to honor that change for
previous installations of llvm-3.8 so the +assertions variant will
remain on your volume until you explicitly install the new -assertions
default variant.

The MacPorts clang-3.8 build (without assertions) seems about 10%
slower than the same under the fink packaging of llvm38/clang38 but
the fink packaging uses the default -O3 optimization whereas MacPorts
resets the build to use -Os instead,

Also, keep in mind that each release of clang has been getting slower
over time as discussed in this thread...

http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html

>
> 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