cmake issue: includes

[David Faure]

On Thursday 30 March 2006 15:21, Adriaan de Groot wrote:
> It remains clear as mud to me *how* the include paths are calculated and where 
> they are set -- and why they are in the order they are. I would largely 
> expect compiles to have the includes in the following order:
> 
> KDE includes
> Qt includes
> Extra includes (is there even an --with-extra-includes functionality?)
> X11 includes

Yes.

> Now, if I look at the compilation of DCOP, I see in DCOP's CMakefile
> 
> include_directories( ${QT_INCLUDES} )
> which adds the Qt includes *at the end of the list to look in*. Why is that 
> even necessary? Why isn't QTDIR/include (or its subdirs) added automatically? 

Because it needs to be before any kdelibs-local includes, as you pointed out
at the beginning of this mail. So I can't just put QT_INCLUDES in the toplevel
CMakeLists.txt, unless we use "include_directories( BEFORE ... )" everywhere,
which people will surely forget to do.

> Why *is* X11_INCLUDES added in the generic includes for everyone?
Someone was lazy, IMHO :)
I agree with your solution, it fits the KDE4_*_INCLUDES set of variables that I set up in kdelibs.

> Anyway, the reason this is a problem for me is that I have Qt3 installed on my 
> system. This is widely regarded as a bad thing. In particular, Qt3 installs 
> includes in /usr/X11R6/include -- this is standard on FreeBSD systems. So now 
> my KDE4 DCOP compiles, which get includes in the order KDE - X11 - Qt pull in 
> Qt3 headers instead of Qt4. The attached patch shuffles things around a 
> little bit: it puts the X11 headers at the end. Is that sensible?

Yes, it looks fine to me, please commit.

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