port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 10:26 AM, René J.V. <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 .


Of course I did...

DEBUG: Executing command line:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build"
&& /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
-DCMAKE_INSTALL_RPATH=/opt/local/lib
-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr"
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules
-DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DLLVM_LINK_LLVM_DYLIB=ON
-DCMAKE_INSTALL_PREFIX="/opt/local/libexec/llvm-3.8"
-DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_RTTI=ON
-DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF
-DLLVM_ENABLE_FFI=ON -DLLVM_BINDINGS_LIST=none
-DFFI_INCLUDE_DIR=/opt/local/include -DFFI_LIBRARY_DIR=/opt/local/lib
-DCMAKE_C_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_OSX_ARCHITECTURES="x86_64"
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.11" -DCMAKE_OSX_SYSROOT="/"
../release_38

[  0%] Building CXX object
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
&& /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/include
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/include
 -pipe -Os -std=c++11 -stdlib=libc++  -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -std=c++11 -DNDEBUG -arch x86_64
-mmacosx-version-min=10.11    -fno-exceptions -o
CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o -c
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen/AsmMatcherEmitter.cpp


>
> 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).
>
> 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).
>
> R