[Kde-bindings] Akonadi and other possibly ambiguous headers

[Richard Dale]

On Monday 21 July 2008 13:31:39 Thomas Schaap wrote:
> Hi,
>
> After having the umptieth compile of trunk go wrong on kde-bindings for
> akonadi I was fed up with it and decided to investigate. The result of
> this were the following surprising lines:
>
> kalyptus: processing /usr/lib/kde4/include/nepomuk/entity.h
>
>
> kalyptus: processing /usr/lib/kde4/include/libkmobiletools/job.h
>
>
> Clearly, these lines should read:
>
> kalyptus: processing /usr/lib/kde4/include/akonadi/entity.h
>
>
> kalyptus: processing /usr/lib/kde4/include/akonadi/job.h
>
>
> Searching the scripts for how the headers were selected I found out it's
> a simple (yet effective) recursive search through the include
> directories. Alas, in the case that a general include directory is used
> to place all KDE4 headers in, this can go wrong due to ambiguities.
>
> To fix these possible ambiguities I suggest to rename all headers in the
> header lists to the names as they're used with in the actual code, such
> as akonadi/entity.h instead of entity.h. Of course, such names are no
> longer accepted by the old way of finding files, so I've written a patch
> to the generate.pl.cmake for akonadi to have it work.
>
> I haven't committed anything, since I'm actually quite sure I've
> overlooked something, if only because this is literally My First Perl. I
> hope someone can convert my patch (attached) to something useful,
> though, and update all of kde-bindings to fix this error and prevent it
> from happening again.
Thanks for the patch, these generate.pl.cmake files really need definatively 
sorting out.

I didn't realize we didn't have an akonadi directory in the header list, and 
as far as I'm concerned not having qualifying directories in the lists of Qt 
or KDE headers is completely borked. At least with the Qt headers there 
didn't used to be name clashes with headers having the same names in 
different directories. But now we have QtCore/qxmlstream.h and 
QtXml/qxmlstream.h which are different and the perl script picks the wrong 
one. In the KDE headers there are about 6 called 'document.h' as far as I can 
remember.

I would rather have just one script in the top level kdebindings/smoke 
directory which could be passed a variable number of header lists to find. 
The names should always be qualified with a directory so that they are 
unique. If your patched version is better than what we have, we can start 
with that.

Originally the Qt headers had the qualifying directory names in them, but 
Caleb Tennis changed that in order to fix the build with framework based Qt 
builds on Mac OS X. I think that change has introduced more problems that it 
has solved. If we only have one script at the top level, perhaps we could 
have a different one for Mac OS X framework headers. At the moment we have 
about 10 slightly different ones with different bugs, and the whole thing is 
a headache.

-- Richard