cmake issue: includes
David Faure
faure at kde.org
Thu Mar 30 14:39:36 BST 2006
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).
More information about the kde-core-devel
mailing list