Q: Rules on inclusion of own headers? how to provide header inclusion kde4-compat? (was: Re: Extending ecm_generate_headers to create cross-forwarding headers?)

David Faure faure at kde.org
Fri Jan 17 08:31:16 UTC 2014


On Thursday 16 January 2014 17:57:51 Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 15. Januar 2014, 12:14:59 schrieb David Faure:
> > On Wednesday 15 January 2014 11:01:55 Friedrich W. H. Kossebau wrote:
> > > Guess you already started to tackle that? :) Or should I give it a try
> > > tonight?
> > 
> > Go ahead :)
> 
> Some questions while I go ahead:
> 
> 1. How should own headers be included, what is preferred?
> #include <kparts/part.h>
> or
> #include "part.h"
> 
> And both the same in the public headers and in the normal sources? Myself I
> also use the second version, but I found a mixture in use, so wonder if one
> is preferred/recommended in the frameworks.

They should both work just the same, I can't see how/when either one would 
break.

I think my preference would be "part.h" in part.cpp (makes it easy for krazy 
to check the rule "include your own header first"),
and <kparts/part.h> in header files -- so that if anyone copies that to their 
own app, it'll work.

> 2. How to do KDE4-compatibility for moved header content?
> 
> E.g. in event.h for KDE4-compatibility the declarations which have been
> moved to their own headers would need to be pulled in again, at least for
> builds using KDE4Support
> Is that done by having includes in the normal file, guarded by a flag, like
> 
> // KDE4 compat
> #if KDE4COMPATIBLE
> #include <kparts/guiactivateevent.h>
> #include <kparts/partactivateevent.h>
> #include <kparts/partselectevent.h>
> #endif

I don't think we need a #if.
The headers installed by kde4support become unavailable as soon as you stop 
linking kde4support. So app who want to be "clean from compat stuff" will 
eventually have to stop using such compat headers, in order to reach the goal 
"does not link to kde4support anymore".

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list