Icinga / Icinga/icinga2

Inconsistent CMAKE_BUILD_TYPE

Open
#9,623 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

core/quality
Dominant language
C++
Stars
2.2k
Forks
616
Avg merge
5d 6h
Merged PRs (30d)
10

Description

Currently, CMakeLists.txt unconditionally adds -g to the compiler flags, resulting in all builds containing debug symbols:

https://github.com/Icinga/icinga2/blob/4b754637f7ac06328d101c72fd03e897707fd352/CMakeLists.txt#L251-L265

I find this surprising as this makes the existence of the two CMAKE_BUILD_TYPES of Release and RelWithDebInfo a bit pointless.

Relevant commits/issues from the past touching this (unfortunately with little reasoning why they did it this way):

Tasks

  • Figure out if using RelWithDebInfo instead of Release makes more difference than passing -g additionally.
  • Prepare PR that does not unconditionally add -g to compiler flags.
  • Test that debug symbol packages are still built properly.
  • Make sure docker builds use the Release type and don't strip the binaries themselves (as introduced by https://github.com/Icinga/docker-icinga2/pull/85)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with CMakeLists.txt around lines 251-265 and compare the Release and RelWithDebInfo configurations. Check the resulting compiler flags, debug symbol packages, and the docker build behavior referenced in the issue. Done means -g is not added unconditionally, symbol packages still build correctly, and docker builds use Release without stripping binaries.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp, docker
Domain
build-system, devops
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.