Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:
> Tyler MacDonald <[EMAIL PROTECTED]> writes:
> [...]
>> 1. If you #include a header directly, you have to depend on that
>> package.
> [...]
I guess you could scan for all directly used include files and then
check with dpkg what packages they belong too. If the Build-Depends
are installed this will have no missing files for files that actualy
do get compiled.
But there might be files in the source that are not used,
e.g. disabled features, and therefore have the includes missing
(rightfully). Detecting what source files are actualy used will be
tricky / impossible. Even detecting common
#ifdef have_foo
#include <foo.h>
#endif
constructs will throw you off course plenty of times. The amount of
false results might just make this unusable overall.
>> 4. If you #include a header that doesn't belong to *any* package
>> (including the source package you're currently building), that's just
>> outright evil.
This will just FTBFS on the buildd or the next full archive rebuild
someobne does. Won't stay undetected for long. Given that you would
need foreknowledge about all include files in all packages to detect
this it seems hardly worth thinking about. Just let it fail.
>> I also think that #1 and #4 would be easy (trivial, even) to catch in some
>> automated way, and that would make an excellent addition to lintian and/or
>> linda...
>
> No. lintian checks packages for policy compliance, it does not run
> checks on the whole archive (which would be needed to implement checks
> for the issues you listed).
Hmm, you wouldn't have to _run_ over the whole archive. The Contents
files, if they ever get fixed, would be enough. The test for (4) could
be conditional on apt-file being installed or something. If the test
is worth anything at all.
> Marc
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
