A New Krazy Checker for #include

Andras Mantia amantia at kde.org
Mon Apr 9 14:05:21 BST 2007


On Monday 09 April 2007, Thomas Zander wrote:
> > This is wrong, you shouldn't do it. If a module has a library, you
> > will have a wrong build if you don't install first the library from
> > the module and then build the rest, otherwise an already installed
> > old version will be picked up.
>
> This problem is irrelevant of wheather you use <> or "" , no?
> The problem you state is that the compiler was passed the installed
> headers dir before the source dir.


And isn't this the difference between using <> or "" ? ;) 

> Note for Alan; if the first point is _only_ tested in header files,
> and then only on ones that actually will be installed then I think it
> looks good.

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.

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 
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...

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070409/a658c2d2/attachment.sig>


More information about the kde-core-devel mailing list