On Fri, Oct 22, 2021 at 10:22:17PM +0200, Vincent Bernat wrote:
> > I'm just thinking, we have a SILENT_DEFINE macro that should already
> > address this. Could you please try to pass your -f... there ? If it
> > works it would just be a matter of improving the SILENT_DEFINE
> > description to indicate that it works as well for compiler options
> > that we don't want to see on the output.
>
> I don't use it directly, it's pushed by Debian build system with some
> other flags. I could puts all of them (-g -O2
> -ffile-prefix-map=/home/bernat/code/exoscale/haproxy=.
> -fstack-protector-strong -Wformat -Werror=format-security) in
> SILENT_DEFINE, but if at somepoint, some of them are more invasive, it
> would may not be a good idea to hide them out of your view.
We could see it differently. The build options that are reported in
the output are there for two purposes:
- help figure what options end users have enabled when they don't
remember ;
- help developers figure what was used to build an executable that
behaves strangely during development cycle
None of these is really useful for a distro's standard flags: as long
as you know what flags you're using to build your packages, packages
built with the distro's default settings don't need to report these
ones. We're doing the same at work in the appliances to pass options
that define some strings such as the build date, model names or
update URL, that are reported on the stats page (and as a byproduct
it saves us from having to double-encode strings :-)).
So I think it's really not a problem to use that as long as your
options are well defined.
Just my two cents,
Willy
