On Tue, Feb 14, 2023 at 09:51:50AM +0000, Simon McVittie wrote: > 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. Right, when I said "record the compiler flags", I did not mean "and always pass them on verbatim". I think you may already know this, since you talk about Python, but yeah, in Python's case things are really not that simple. This command: python3 -c 'import pprint; import sysconfig; pprint.pp(dict(item for item in sysconfig.get_config_vars().items() if "CFLAGS" in item[0]));' ...displays all of the "system configuration variables" (pretty much exactly things recorded at Python build time) that have "CFLAGS" in their name, and at least with Python 3.11 in testing, there are *a lot* of those. Some of them are obviously module-specific configuration for the various Python standard library modules, but there are others, too. Other systems record compiler (and linker, etc) flags with different granularity, but yes, you are correct that it makes a lot of sense to take care what is recorded and how. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature