A New Krazy Checker for #include

[Thiago Macieira]

Andras Mantia wrote:
>It can be still wrong. Let's say KDE module "kdefoo" has a "kdefoolib"
>library with the following installed headers:
>foo.h
>bar.h
>
>bar.h has:
>#include <foo.h>
>class Bar : public Foo {
> ...
>};
>
>
>The rest of the "kdefoo" module has applications depending on this
>library.

Ok, sounds fine.

>When you already have an old version of the kdefoo module (and thus the
>library) installed and you build a new version of the module, when the
>kdefoolib is build, and bar.h is included, it will include the
>installed "foo.h", instead of the local one. If there are differences

No, it won't.

When you're building kdefoolib, it should have -I$srcdir -I$objdir in the 
compilation command line, so that it finds the proper headers.

This means that #include "" and #include <> make no difference in the .cpp 
file either.

>between them, you have problems.
>This can be avoided by using "foo.h" there, or by explicitely passing
>the current source dir to the include flags of the compiler, but nobody
>will do it unless there will be an error...

Exactly what I said above.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070409/b287f78e/attachment.sig>