LibXml for Linux is not picked up by CMake

[mcraveiro]

Hi,

Not quite sure if this is a conan issue or not, but thought I'd mention it in case it is. So I've started consuming LibXml for Linux, and the conan part of it works fine (download, install, etc) [1]. However, FindLibXml then reports this:

- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.7.8") 

This is probably because the /usr/lib dirs are first in the CMake include order. Which makes me think, should conan define CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH to point to the installed packages? Does it do this already? Presumably this would ensure picking up stuff from conan first.

Could this also remove the need for the conan overrides of FindBoost as well?

Cheers

Marco

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/99770552

[lasote]

Hi Marco,

CMake needs a custom findXXX.cmake file in every package in order to find them trough a find_package(XXX). My packages do not provide yet a findXXX.cmake. I will upload soon!

Actually, CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH are pointing to your libxml packages, but find_package do not use those variables to find the sources (yeah, it's annoying). Those custom find_package files do a lot of crazy things looking in common paths, appending common names and many other, but never look in CMAKE_LIBRARY_PATH.

Meanwhile you can omit the use of find_package and just link with CONAN_LIBS_LIBXML2 or the global CONAN_LIBS

Thanks for try it Marco!
Cheers

[mcraveiro]

Hi,

Well, you probably know CMake better than I do to be honest :-) I never looked at this in detail, but up till now I have been using these to supply the path to my local installs of boost, like so:

CMAKE_INCLUDE_PATH=/usr/local/personal/include CMAKE_LIBRARY_PATH=/usr/local/personal/lib CC=gcc-5 CXX=g++-5 cmake ../../../ -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DWITH_LATEX=FALSE && ninja -j5

This has worked fine for me locally, with the personal boost version taking precedence over the system installed one (and no changes required in the find boost etc). I also did this for windows using NuGet packages (LibXml) and it worked as well. Finally I did a quick search and found some other guys doing something similar for Qt on Windows [1]. I'm wondering - could it be CMake has changed behaviour recently since you guys looked at it?

Cheers

Marco

[1] http://stackoverflow.com/questions/10571249/cmake-qt-and-cmake-include-path

[lasote]

Interesting! I looked again to CONAN_BASIC_SETUP and we are not setting directly CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH, I was wrong.

We are just calling to:

INCLUDE_DIRECTORIES(${CONAN_INCLUDE_DIRS}) 
LINK_DIRECTORIES(${CONAN_LIB_DIRS})

So maybe there is some unknow (by me) behaviour with CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH.

Thanks so much, I will try it!

PD: I think the key is that the findXXX recipes calls to find_library, and find_library looks in custom paths and "system" paths. Probably setting CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH will add places to look as "system" paths. Looks good!

[mcraveiro]

excellent, great news!

[lasote]

It works!

I've open a PR, it will be (at least we find some problem) in conan 0.6
You can paste these lines after CONAN_BASIC_SETUP() call to fix all find_packages until we release conan 0.6

SET(CMAKE_INCLUDE_PATH ${CONAN_INCLUDE_DIRS} ${CMAKE_INCLUDE_PATH})
SET(CMAKE_LIBRARY_PATH ${CONAN_LIB_DIRS} ${CMAKE_LIBRARY_PATH})

Thanks a lot, its a big improvement! 👍

[mcraveiro]

No worries! I'll wait for v0.6 - it will get automatically picked up by the CI :-) I'll report back then.

Muchas gracias!