config.h

David Faure faure at kde.org
Tue Apr 10 09:22:04 BST 2007


On Tuesday 10 April 2007, Allen Winter wrote:
> On Monday 09 April 2007 7:34:49 pm David Faure wrote:
> > On Tuesday 10 April 2007, Allen Winter wrote:
> > > Howdy,
> > > 
> > > There's still quite a few files that include config.h.
> > Yep.
> > 
> Ok, so for kdelibs:
>  - remove the -DHAVE_CONFIG_H from the toplevel CMakeLists.txt
>  - remove the #ifdef HAVE_CONFIG_H wrapper everywhere it is found
> Correct?

Yes.

And I guess the discussion below should go into some wiki page?

David.

> > > And even more that don't have
> > > #ifdef HAVE_CONFIG_H
> > > #include <config.h>
> > > #endif
> > Good that they don't.
> > That ifdef made already little sense in kde3 times, it makes even less sense nowadays ;)
> > 
> > > We do pass -DHAVE_CONFIG_H into the buildsystem (see kdelibs/CMakeLists.txt).
> > We do in kdelibs, but I removed it from a number of modules - those were I removed config.h files altogether.
> > 
> > > So:
> > > 1. didn't we plan to replace config.h with config-foo.h to increase modularity?
> > Yes. And we should keep doing this everywhere.
> > However, I see three exceptions:
> > 1) kdelibs, where a lot of system-specific defines are used everywhere, which makes
> > sense since kdelibs wraps some platform-specific things for the rest of KDE (much like
> > Qt wraps many more). Individual features (e.g. ACL-stuff) goes nicely into config-acl.h,
> > but the rest is... well, basically libc-level checks for includes and functions, I can't see
> > much logical grouping that can be done there.
> > 2) third-party libraries which we have a copy of, and which refer to a config.h - but then 
> > I recommend to make it local to that lib, like for instance I added kdepimlibs/kcal/libical/config.h.cmake
> > for that purpose.
> > 3) individual applications that use config.h for all its dependency-related defines, like e.g. amarok.
> >  Well ideally I'd rather see that splitted into one config-foo.h file per dependency but at 
> >   least it's a config.h with an application scope, which is already much better than a config.h 
> >   for a whole svn module (which makes it *really* difficult to move things around later on).
> > 
> > > 2. if we are compiling fine with including config.h unconditionally,
> > >     then do we still need to pass -DHAVE_CONFIG_H?
> > >     or should we wrap all the includes inside the #ifdef?
> > We should for sure get rid of the ifdef everywhere. If the code is in one of the 3 cases aboves
> > and relies on a config.h then it should just include it.
> > 
> 
> 
> 
> -- 
> KDEPIM Developer
> I accept PayPal payments to awinterz at earthlink.net
> 
> 



-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list