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). Is there a reason the LLVM ports build a shared libLLVM? R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
