Mir

debian.cmake slows down the build and should not be needed

Bug #1149562 reported by Jussi Pakkanen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Undecided
Jussi Pakkanen

Bug Description

The Debian.cmake grabs all build flags from dpkg-buildflags. This is problematic because one of the flags is -O2, which slows down compilation. A quick test shows that simply commenting out include(cmake/Debian.cmake) from the main CMakeFile cuts down compile time by 30%. The other big problem with -O2 is that it makes debugging a massive pain, because trying to print out the values of variables often just prints "value optimized out".

The debian.cmake file should really not be needed at all because of the following reasons:

1. when a package is built, debhelper (or whatever it is) will pass the flags directly to CMake so they are always correct

2. the CMake way of selecting between optimized and non-optimized builds is with the CMAKE_BUILD_TYPE option. Changing optimization behaviour behind the user's back is confusing.

3. If extra warning flags should be on at all times (stack protector etc), then they can be added in the same manner as --std=c++0x.

Therefore Debian.cmake should be just removed or, at the very least, there should be an option flag to enable it and by default it should be off.

Related branches

Revision history for this message
Thomas Voß (thomas-voss) wrote :

The point here is that we want enable developers to build in an environment with a setup as similar to the package build setup as possible. On the one hand, the package build setup is in general quite sane, on the other hand we want to avoid surprises w.r.t. packaging builds failing that were difficult to reproduce on developer's machines.

Revision history for this message
Jussi Pakkanen (jpakkane) wrote :

There is nothing wrong with providing this functionality but due to the reasons described above it should not be on by default.

This problem can better be solved by educating people to use multiple build directories. Not only is it the Right Thing To Do, it also increases productivity. For those who don't know CMake supports separating build directories from the source. Those build directories are completely separate of each other and the source tree and you can have as many of them as you want. This allows you to have multiple configurations always ready to build and test. As an example you could have these directories:

build # Regular non-optimized debug build, that builds fast for every day development
buildrelease # Optimization on, for testing and perf analysis
buildclang # Build with Clang compiler to catch more bugs
buildscan # Build with Clang's static analyzer to
buildcoverage # Build with coverage flags enabled
buildcross # build with a cross compiler to platform X

The beauty of CMake is that you can cd into any directory and type make (or ninja, if you want it to be fast) and it will build the correct thing. No matter how old your build directory is or what changes you have done to your source tree since the last run. It wil just work.

Taking all that into considerations the change required to make package flags optional is simple. Change this line:

include (cmake/Debian.cmake)

into this:

option(use_debflags "Use build flags from dpkg-buildflags." OFF)
if(use_debflags)
  include (cmake/Debian.cmake)
endif()

Changed in mir:
assignee: nobody → Jussi Pakkanen (jpakkane)
status: New → In Progress
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision 499, scheduled for release in mir, milestone 0.0.2

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
milestone: none → 0.0.3
Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.