kernel: MK_REPRODUCIBLE_PATHS for full paths vs /usr/src

[imp]

Summary

There are many environments that you do not want the paths to be
canonicalized. For example, if I always build a product from a specific
path in a jail that's dependent on the product version, I don't want
that to be sanitized to /usr/src because when I have profiling tools run
against multiple kernels, I can't do A/B testing and results processing
if everything points to /usr/src (and no, the profiling tools cannot
remap back to the original like gdb can). Since we need both active at
the same time, symbloic link fallbacks don't work.

We do want the rest of the build to be reproducible, however. We'll get
the same binaries if we rebuild later.

Sponsored by: Netflix

[ivy]

sys/conf/kern.opts.mk

66

if i understand this correctly, this means WITH_REPRODUCIBLE_BUILD will automatically enable WITH_REPRODUCIBLE_PATHS. that's not a good idea if we will make reproducible builds the default, because it will break everyone's debug info in a rather non-obvious way.

[gallatin]

sys/conf/kern.opts.mk

66

I'm not a bsd mk expert, but I think this preserves the current behavior, where WITH_REPRODUCIBLE_BUILD results in debug syms as if they were in /usr/src

The behavior I want is WITH_REPRODUCIBLE_BUILD enabled and WITH_REPRODUCIBLE_PATHS disabled. So that the build is reproducible, but the debug symbols point to the src code in /my/crazy/maze/of/git/repos

The current behavior seems correct for pkg builders trying to make binaries where users can generate meaningful bug reports, but torpedos my workflow because it points everything at /usr/src rather than where my source trees really live, making debugging and profiling painful.

[imp]

I'm cool with it off by default too.
But then I'd have to hunt down the builds scripts for the release and add it there :)

[ivy]

In D52959#1210211, @imp wrote:

I'm cool with it off by default too.
But then I'd have to hunt down the builds scripts for the release and add it there :)

i remember someone on IRC floated another idea like WITH_RELEASE_BUILD_OPTIONS (or something with a better name -- i don't remember exactly) which would turn on all of this stuff. that seems like a reasonable approach to me, and we could potentially also use it for @emaste's PKG_LEVEL setting. at least then you'd only need to update the release bits once.

[imp]

Ignore me