port:libclang (and libLLVM)
René J.V. Bertin
rjvbertin at gmail.com
Thu Mar 10 13:47:01 PST 2016
On Thursday March 10 2016 14:24:00 Ryan Schmidt wrote:
> > CMake does something similar for all 4 built-in presets, so the only way I know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a custom value. Debian/Ubuntu do that in their packaging scripts (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake doesn't have a dedicated variable for preprocessor options).
> If so, that would be yet another bug, or yet another broken-by-design feature, of cmake.
I tend to agree, but it depends on how you look at the concept of presets ...
> > Here's something much more interesting though: I just discovered that llvm and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
> > What's going on here??
> My llvm-3.4 is 436MB, llvm-3.7 765MB.
Are those the tarball sizes, or the unpacked sizes?
> I don't know why mine are the size they are and yours are the size they are.
Differences due to OS version and thus the used compiler?
> You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the size difference lies.
You did notice that I repackaged the images as xz'ed tarballs, right? That does make a considerable difference for llvm and clang.
According to xz, the llvm-3.7 tarball is 1628.6Mb uncompressed, llvm-3.6 1326Mb, llvm-3.8 107.3Mb . The llvm-3.8 destroot I just built (without shared libllvm and without RTTI support, using MacPorts clang 3.7 and -O3 -march=native) is 387Mb.
More information about the macports-dev