Describe the enhancement requested
As discussed here:
When running reprotest inside the docker container we can see that the build path variation causes some issues on our code base. We might be taking a different approach in order to solve some issues (like meson generated pkgconfig files containing the build path on Libs.private) but adding the build path on some areas can be fixed, for example:
Shared object including the compilation options as a string, which includes the build path:
│ │ │ │ │ │ │ String dump of section '.rodata.str1.8':
│ │ │ │ │ │ │ [ 0] basic_string: construction from null is not valid
│ │ │ │ │ │ │ [ 38] Arrow was set to use OS timezone database at compile time, so a downloaded database cannot be provided at runtime.
│ │ │ │ │ │ │ + [ b0] -Wredundant-move -Wno-noexcept-type -Wno-self-move -g -O2 -ffile-prefix-map=/tmp/reprotest.1LefKs/build-experiment-1/apache-arrow-22.0.0~dev20251020=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -D_FORTIFY_SOURCE=2 -fdiagnostics-color=always -Wall -Wno-conversion -Wno-sign-conversion -Wdate-time -Wimplicit-fallthrough -Wunused-result -fno-semantic-interposition -msse4.2
│ │ │ │ │ │ │ - [ b0] -Wredundant-move -Wno-noexcept-type -Wno-self-move -g -O2 -ffile-prefix-map=/tmp/reprotest.1LefKs/const_build_path/apache-arrow-22.0.0~dev20251020=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -D_FORTIFY_SOURCE=2 -fdiagnostics-color=always -Wall -Wno-conversion -Wno-sign-conversion -Wdate-time -Wimplicit-fallthrough -Wunused-result -fno-semantic-interposition -msse4.2
Or the generated mkenums containing the full build path:
│ │ │ │ ├── ./usr/include/gandiva-glib/enums.h
│ │ │ │ │ @@ -24,20 +24,20 @@
│ │ │ │ │
│ │ │ │ │ #include <glib-object.h>
│ │ │ │ │
│ │ │ │ │ #include <gandiva-glib/version.h>
│ │ │ │ │
│ │ │ │ │ G_BEGIN_DECLS
│ │ │ │ │
│ │ │ │ │ +/* enumerations from "/tmp/reprotest.1LefKs/build-experiment-1/apache-arrow-22.0.0~dev20251020/c_glib_build/../c_glib/gandiva-glib/native-function.h" */
│ │ │ │ │ -/* enumerations from "/tmp/reprotest.1LefKs/const_build_path/apache-arrow-22.0.0~dev20251020/c_glib_build/../c_glib/gandiva-glib/native-function.h" */
│ │ │ │ │ GGANDIVA_AVAILABLE_IN_ALL
│ │ │ │ │ GType ggandiva_result_nullable_type_get_type(void) G_GNUC_CONST;
│ │ │ │ │ #define GGANDIVA_TYPE_RESULT_NULLABLE_TYPE (ggandiva_result_nullable_type_get_type())
│ │ │ │ │
│ │ │ │ │ +/* enumerations from "/tmp/reprotest.1LefKs/build-experiment-1/apache-arrow-22.0.0~dev20251020/c_glib_build/../c_glib/gandiva-glib/selection-vector.h" */
│ │ │ │ │ -/* enumerations from "/tmp/reprotest.1LefKs/const_build_path/apache-arrow-22.0.0~dev20251020/c_glib_build/../c_glib/gandiva-glib/selection-vector.h" */
│ │ │ │ │ GGANDIVA_AVAILABLE_IN_ALL
│ │ │ │ │ GType ggandiva_selection_vector_mode_get_type(void) G_GNUC_CONST;
│ │ │ │ │ #define GGANDIVA_TYPE_SELECTION_VECTOR_MODE (ggandiva_selection_vector_mode_get_type())
│ │ │ │ │
│ │ │ │ │ G_END_DECLS
We shouldn't be adding the build path on those.
Component(s)
C++, GLib
Describe the enhancement requested
As discussed here:
When running reprotest inside the docker container we can see that the build path variation causes some issues on our code base. We might be taking a different approach in order to solve some issues (like meson generated pkgconfig files containing the build path on Libs.private) but adding the build path on some areas can be fixed, for example:
Shared object including the compilation options as a string, which includes the build path:
Or the generated mkenums containing the full build path:
We shouldn't be adding the build path on those.
Component(s)
C++, GLib