Re: Bug#1030785: -ffile-prefix-map option and reproducibility

[Simon McVittie <smcv@debian.org>]

On Tue, 14 Feb 2023 at 10:21:31 +0200, Peter Pentchev wrote:
> I can't speak of many other systems, but at least with Perl's XS
> (the standard way to write Perl modules parts of which are compiled C code)
> and two of the ways this can be done in Python, it is the same:
> the C compiler's name and flags are recorded at the time the "wrapper" is
> built, so that they can be used later. At least IMHO, this has two main
> benefits:
> - people (or programs) that want to build a Perl/Python/OCaml/whatever
>   module do not have to know anything about C compilers, flags, optimization,
>   language-specific libraries[1] , etc. The consumers tell their own language
>   ecosystem "look, I need to compile something that has C parts in it, go do
>   something about it", and the wrapper for the C compiler knows exactly what
>   to do
> - everything is compiled using the same compiler[2], the same optimization
>   flags, the same libraries, etc., so one module that has C parts in it can
>   call the C functions from another module directly with no fear of any kind
>   of calling convention mismatch or whatever

I think this is very common, but really a bit too simplistic. Some of
the compiler flags are part of an interface between components, and for
those flags, it makes sense to record them in the compiler-wrapper or
in some metadata file like a pkg-config .pc file; but some of them are
private implementation details of the component currently being compiled,
and don't make sense to replicate between components.

For instance, -lpython3.11 is certainly part of the interface, -O2 -g
is not part of the interface *on Debian* but might be on other platforms
(on glibc systems there's only one C runtime library, but Microsoft
compilers use different and incompatible runtime libraries for release and
debug builds), but facts about the build directory like
-I/tmp/python3.11-3.11.2/Include or
-ffile-prefix-map=/tmp/python3.11-3.11.2=. are certainly not part of the
interface.

Neither are warning-control options like -Wall or
-Werror=implicit-function-declaration, really: just because the Python
maintainers want warnings or even errors when comiling Python, that
doesn't necessarily mean it's right to require all Python extension
modules to be built with those same warnings.

    smcv