On Sun, Apr 23, 2006 at 11:33:53AM +0200, Alexander Neundorf wrote:
> Hi,
Hi,
why the cross-post? This is definitely a buildsystem question...
Removing kde-core-devel from the cc.
> When building a KDE module, it is required that it prefers the headers in the
> module sources over the installed headers.
Could maybe the solution be that cmake automatically puts all
-I<relative path>
before all
-I<absolute path>
?
This would solve the problem once and for all, and without any risk
of people getting it wrong in the CMakeLists.txt files - like they all
did in Makefile.am times, and I have to fix those files over and over again.
Of course the relative order inside each group would be kept, so that
adding paths like relA absA relB absB would give on the command line
-IrelA -IrelB -IabsA -IabsB.
I'll comment on your proposal below just in case the above doesn't make
sense for some reason, but I think that it does ;)
> This would mean we could do the following in the toplevel CMakeLists.txt :
>
> # default to prepending
> set (CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
> include_directories( ${KDE4_INCLUDES} )
Hmm, with the option on, this means everything we wrote up to now
(local includes, global includes) would be wrong....
> and then in the subdirs:
> include_directories( ${CMAKE_SOURCE_DIR}/foo ${CMAKE_SOURCE_DIR}/foo/bar )
btw does this make /foo/bar appear before /foo?
or is include_directories(A) include_directories(B) now different from
include_directories(A B), with the option on?
I foresee some confusion...
> This would work for this case, but there's also the case that include dirs of
> other software package have to be added, like:
>
> include_directories( ${PNG_INCLUDE_DIR} )
Yes. Or simply some qt or kde sub-module that is needed by some code only.
(e.g. QtXml/, or kparts/)
> So, I'd suggest:
> -keep the default ordering, i.e. appending
> -for include dirs, which are inside the source/build tree, always use the
> BEFORE keyword
> -for all other include dirs, always use the AFTER keyword
I think - no I know - that people will get it wrong and will forget BEFORE.
Why? Because it will work for them even without it.
Forgetting before is like forgetting to put all_includes after local includes
in Makefile.ams - it only breaks when the installed headers are older and
incompatible with the local headers, which happens more often to people
who compile the code than to people who work on the code (since they make
install more often).
But if my idea at the top of this mail can't be done, then I guess you're right,
your solution is still better than the current once since it allows to factorize
the setting of KDE4_INCLUDES into the toplevel.
> I think this should work for most cases. And I think we should even go that
> far to add a commit hook, which complains if INCLUDE_DIRECTORIES() is used
> without BEFORE or AFTER, giving a warning right now (is this possible ?) and
> reject the commit once everything builds reliably with cmake.
Can't we then simply redefine include_directories so that it barfs if neither
BEFORE nor AFTER was passed? If something can be checked by cmake or a cmake
macro, it would be better than checking when importing (which only happens
for code in kde svn but not for 3rd party code).
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
