omit build path

[maitbot]

Support reproducible builds by replacing reference to the build path.

Description

Because gnuradio wants to take it's set of compiler flags so that
gnuradio-config-info --cflags
can show them to the user later, this was also capturing the -ffile-prefix-map
that the Debian package build uses to keep the build path out of generated files.

Also: Doxyfile.in needed an update to its STRIP_FROM_INC_PATH config.

Related Issue

Last year's commit, 886485a :
runtime: Move block_gateway from gnuradio-runtime into gr_python
resulted in the build path showing up in the Doxygen docs again.

Which blocks/areas does this affect?

In gnuradio-runtime this replaces the actual build path with a generic
"BUILD_DIR" string.

Testing Done

Debian's lintian tool detects when the build path is found within
files generated and installed for packaging.
Applying this patch gave a clean report in preliminary packaging of
gnuradio 3.10.8.0-rc1

Because this patch also applies to the maint-3.10 branch, please consider including this
before the next release 3.10.8.0

Checklist

• I have read the CONTRIBUTING document.
• I have squashed my commits to have one significant change per commit.
• I have signed my commits before making this PR
• My code follows the code style of this project. See GREP1.md.
• I have updated the documentation where necessary.
• I have added tests to cover my changes, and all previous tests pass.

[willcode]

From CI:

CMake Error at gnuradio-runtime/lib/CMakeLists.txt:23 (cmake_path):
  Unknown CMake command "cmake_path".

[maitbot]

Rats. cmake_path
New in version 3.20.

... so, how can one find a parent path in old-fashioned CMake?

[maitbot]

I'd be happy if someone came up with a CMake function that could simply remove the
-ffile-prefix-map flag entirely.

It would be useful for volk and UHD too.

[ryanvolz]

Conceptually I think this is about the best that could be done to get reproducible builds. I don't see a better way than stripping out paths manually. Instead of cmake_path, I'm guessing you'd need something with get_filename_component for compatibility with CMake < 3.20.

I also think we could go further and just drop the compiler flags altogether from the constants file and and gnuradio-config-info. I don't really see what value they provide to make them worth worrying about stripping paths.

[balister]

Please remove all build time/system info from these files. I am also carrying patches in meta-sdr to support reproducible builds of gnuradio.

For example:
https://github.com/balister/meta-sdr/blob/master/recipes-core/gnuradio/files/0001-Compiler-flags-include-build-system-paths.patch

[ryanvolz]

If we do want to keep some form of the compiler flags, maybe it would be better to define what the useful information is and use a regex to keep only that specific information. Then if compiler flags get added somehow in the future that would break reproducible builds, those wouldn't flow through to the output.