On Mon, Aug 07, 2023 at 06:43:36PM +0000, Benjamin Drung wrote: > Hi, > > while working a whole week on fixing failing C/C++ header compilations > for armhf time_t [1], I noticed a common pattern: The library -dev > packages was missing one or more dependencies on another -dev package. > Over 200 -dev packages are affected. > > I propose to add an autodep8 test for C/C++ header files that tries to > compile the header file. This will catch issues like missing > dependencies and other issues. > > Here is a draft for the autopkgtest check script that takes a binary > -dev package as parameter: > https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check > > What do you think? Should I proceed developing and packaging this check > script and submit support for it in autodep8? > > [1] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/103 Whlie it does seem an interesting tool at first glance (and thanks for doing the work and presenting a proof of concept), I can think of several cases when compilation of the concatenated header files would fail: 1) The library has a "main" header file that must be included before any of the others, and it does not come first in lexicographical order. It may define typedefs and structure definitions that the other header files can use, it may define preprocessor symbols that reflect the availability of this or that system header file or type; there are also other ways in which another header file distributed by the -dev package may depend on the main one. 2) As a variation of the above, the -dev package may distribute the full set of header files included in the library, and some of them may only be included if certain preprocessor symbols are defined. Since their use is guarded by conditionals, they are allowed to unconditionally include system-specific header files that are only available on e.g. Windows or NetBSD or Darwin, etc. Unconditionally compiling the contents of those files would fail. 3) The -dev package may distribute the full set of header files included in the library, and some of them may be mutually exclusive and impossible to combine. For example, a header file may include either this or that other header file based on preprocessor defintions (OS type, features enabled, etc), and the included files may both define a function with the same name, but different contents. 4) Some of the library's header files may not be supposed to be included in all cases; the library's -dev package may suggest (but not depend on or recommend) another -dev package as an optional dependency, and a library's header file may unconditionally include some header file from the latter package. All of these cases are things I've seen in complex libraries with many header files; maybe not all of them can be found in Debian right now. So... yeah. Thanks for your work, I know you mean well and you are trying to make the life of Debian developers better, but this particular approach will likely fail on a non-trivial set of Debian -dev packages. 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