Helmut Grohne <hel...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
