port:libclang (and libLLVM)

Ryan Schmidt ryandesign at macports.org
Thu Mar 10 12:24:00 PST 2016


> On Mar 10, 2016, at 9:26 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
> 
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>> 
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
> 
> Did you look at the actual compile commands? Again, cmake is used, and when you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because those presets will override it with -O2 .
> 
> 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.


> 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:
> 
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--    1 bertin admin 158M Nov 15 19:10 llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--    1 bertin admin 188M Jan  9 21:11 llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--    1 bertin admin 15M Mar 10 16:08 llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--    1 bertin admin 169M Nov 15 19:17 clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--    1 bertin admin 182M Jan  9 21:34 clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.8:
> total 17M
> 17M -rw-r--r--    1 bertin admin 17M Mar 10 16:14 clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz
> 
> 
> What's going on here??
> 
> If that means that building from source also takes comparatively less time and resources I might be inclined to experiment with non-shared builds, or a build without RTTI support (even if that apparently should account for no more than 5% performance loss).

My llvm-3.4 is 436MB, llvm-3.7 765MB. 

I don't know why mine are the size they are and yours are the size they are.

You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the size difference lies.



More information about the macports-dev mailing list