Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
Helmut Grohne <helmut@subdivi.de> writes:
> more and more packages implement a technique called profile guided
> optimization. The general idea is that it performs a build that is
> instrumented for profiling first. It then runs a reasonable workload to
> collect profiling data, which in turn is used to guide the optimizer of
> a second build which is not thus instrumented. The idea is that this
> second build probably is faster than a regular build.
> Quite obviously this approach completely breaks cross building. It also
> is unclear how it affects reproducible builds since such builds depend
> on the performance characteristics of the system performing the build.
> This makes it very obvious that the pgo technique has downsides that
> warrant disabling it in some situations.
> A number of packages have agreed on disabling such optimization when
> DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages:
> * binutils
> * cross-toolchain-base
> * gcc-VER
> * halide
> * pythonVER
> I'll also be filing a patch for foot to support this option.
> Is this sufficient coverage to document the option already?
Yes, I think that's plenty. I would love to have Policy be a bit more
proactive about documenting things like this.
> Proposed wording:
> This tag requests that any optimization performed during the build
> should not rely on performance characteristics captured during the
> build. Such optimization is usually called profile guided
> optimization.
Could you specifically mention cross-building (and possibly reproducible
builds) as an example of why someone may want to set this option? I think
having those sorts of explanations add a lot of value to Policy, since
they help explain to the reader how Debian is designed beyond just a
mechanical set of instructions.
If you have a chance, feel free to send a proposed diff to add this to the
DEB_BUILD_OPTIONS section.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: