What is the purpose of having the build flags in a file in the .deb?
Hi,
Le 08/02/2023 à 10:58, Emilio Pozuelo Monfort a écrit :
What is the purpose of having the build flags in a file in the .deb?
ocamlc can act as a driver for the C compiler, to compile C stubs with the "right" flags. These flags are basically the CFLAGS ocaml was compiled with, plus some additional OCaml-specific flags (like -fwrapv).
But I wonder now: shouldn't the CFLAGS part be queried from the environment at use time, rather than at OCaml compilation time? This setting of a non-C compiler calling a C compiler must happen often... I don't know what's the practice elsewhere.
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
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:06:43 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |