/usr/include priority vs custom include paths

Mateusz Łoskot mateusz at loskot.net
Sun Oct 30 14:04:26 GMT 2011


On 30 October 2011 08:14, Andreas Pakulat <apaku at gmx.de> wrote:
> On 29.10.11 20:24:13, Mateusz Łoskot wrote:
>>
>> I use two versions of Boost C++ libraries installed.
>> Boost 1.42 installed from .deb packages with headers in /usr/include.
>> Current Boost trunk with headers in my workshop folders inside $HOME.
>> Namely, in /home/mloskot/dev/boost/_svn/trunk.
>>
>> I have configured "Custom include paths" this way:
>>
>> http://www.flickr.com/photos/mloskot/6291933457/
>
> Oh that one is new, great that once again someone needed to invent a
> gui again instead of re-using some existing :|

I'm not sure I understand. Have I invented anything here?

>> My CMakeLists.txt however adds include directory from my Boost trunk location.
>
> Why? If you open a cmake project in kdevelop kdevelop will automatically
> pick up all include directories as configured in cmake (except for some
> bugs of course).

This is confusing:

"Why? (...) kdevelop will automatically pick up all include
directories as configured in cmake"

That's why I have to configure my project adding it to CMakeLists.txt file.

Here is what I do:

1) In my CMakeLists.txt I do this:

find_package(Boost 1.48 REQUIRED)
if(Boost_FOUND)
  include_directories(${Boost_INCLUDE_DIRS})
endif()

2) In  "Configure Project" dialog, in advanced I have
Boost_INCLUDE_DIR=/home/mloskot/dev/boost/_svn/trunk
(I know I can all cmake with BOOST_ROOT, etc. I know very well
how FindBoost.cmake module works, it's not really relevant to my question.)

Then, my project is compiled using headers from Boost trunk location,
instead of /usr/include.

Am I right?

>> The parser reports searched include path a follows:
>>
>> 1. project directory, which is in my case /home/mloskot/workshop/boost
>> 2. then /usr/include
>> 3. custom include paths: /home/mloskot/dev/boost/_svn/trunk
>> 4. other /usr/... includes
>
> If you're using a cmake-based project and kdevelop picks up includes
> from cmake, then this is wrong. For any given header file the cmake
> plugin must be able to report the exact include's for that file and the
> c++ support must use only those for searching. Anything else is a bug in
> either of the two plugins.

So, if I understand it correctly, in order to
1) make my project compiling against my Boost trunk
2) make kdevelop parsing/reporting headers from my Boost trunk
I only need to configure my CMake-based project to point to Boost trunk
(as explained above). I do not need to edit "Custom include paths".
Is that right?

If my understanding is correct, then I will clean all settings, create
it as they should be,
and see if it works. If not, I should report to bugzilla, I guess.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org




More information about the KDevelop mailing list