Re: Prevent dpkg-buildflags from overwriting any (or at least some) flags during compilation

Hi!

On Sat, 2023-07-22 at 13:12:28 +0200, Guillem Jover wrote:
> [ This feels more like a packaging question than one for dpkg development,
>   please redirect further replies to debian-mentors(?) now on Cc. :) ]

[ Sorry noticed the typo in the mentors list address just when I was
  sending the mail. :/ ]

> On Wed, 2023-07-12 at 15:21:26 +0200, Jędrzej Dudkiewicz wrote:
> > I have few projects that I pack for our internal use. I use `debuild`
> > to compile them. They all use CMake. CMakeLists.txt contains carefully
> > selected sets of flags that we want to use. Unfortunately when the
> > package is built, `debuild` overrides a few flags (it adds -g, changes
> > -Os to -O2) and we definitely don't want that. Is there some way to
> > prevent `dpkg-flags` from changing them?
> 
> Usually with build systems you should be able to denote what compiler
> flags are required (or well, highly desirable) and which ones are
> truly optional. Say the difference in a Makefile between:
> 
>   CFLAGS ?= optional such as -O2.
>   CFLAGS += required such as -fwrapv or highly desirable such as -Wbar.
> 
> or similar. For dpkg itself for example, the build system will default
> to check for the availability of lots of warning flags and append them
> unconditionally, but makes it possible to disable this behavior by
> passing --disable-compiler-warnings to ./configure. I assume you could
> do something similar with CMake.
> 
> > I don't want to repeat those flags in debian/rules as this way I will
> > have to change them in two places in case any of them changes.
> 
> Ack.
> 
> > Is there some simple way to avoid usage of `dpkg-buildflags` during compilation?
> 
> This depends on how dpkg-buildflags is being called, if you had a
> hand-crafted debian/rules, then you can control how to call it. But if
> using dh/debhelper, then not really, because that seems a bit counter
> to what both debheler and dpkg-buildflags are supposed to be doing.

Thanks,
Guillem