FCL cannot find libccd installed on $HOME/.local

[xinyazhang]

I installed my custom built libccd under $HOME/.local/lib/x86_64-linux-gnu/ (because I don't have the root access to the machine I'm using), and current FCL 0.6.1 cannot find the installed libccd even if pkg_check_modules(PC_CCD ccd) sets PC_CCD_FOUND be 1.

After digging into this problem for a while I found

1. pkg-config -cflags ccd would print empty if the include directory is one of the default locations.
2. pkg_check_moudules uses pkg-config -cflags to locate the include dir
3. The FCL's CMakeLists.txt uses <prefix>_INCLUDE_DIRS to find the header, which depends on the output of pkg-config -cflags
4. Thus, if libccd is installed at one of the default locations and cannot be found through find_package, the pkg_config method will fail because <prefix>_INCLUDE_DIRS is empty.

[v4hn]

I'm just another user of FCL, but also a linux distribution maintainer overlaying modules every day. Your problem is not with FCL, but with your own installation.

FCL expects to find a ccd-config.cmake or a ccd.pc file that point to the version of libccd that you want to use. You can't just copy an so file and/or headers to a folder and expect cmake to find them. Instead it is your responsibility to make sure these files correctly overlay their respective system-wide versions (if those exist).

To make pkg-config aware of files in different locations, you can add the folder to the PKG_CONFIG_PATH environment variable, e.g., export PKG_CONFIG_PATH="$INSTALL_PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH".

For cmake it's somewhat counterintuitive, but you have to extend PATH with an existing $INSTALL_PREFIX/bin folder. cmake will automagically look for $INSTALL_PREFIX/lib.*/ccd/ccd-config.cmake (and all other valid locations) to find the config when find_package(ccd) is invoked.

Of course the files have to provide the correct installations locations as well, but they usually do if you build with -DCMAKE_INSTALL_PREFIX=<your location here>.

[xinyazhang]

To make pkg-config aware of files in different locations, you can add the folder to the PKG_CONFIG_PATH environment variable, e.g., export PKG_CONFIG_PATH="$INSTALL_PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH".

No this is not the case. I would emphasis again, in my configuration the pkg-config is able to locate libccd, and my PKG_CONFIG_PATH is correctly set. I added message to CMakeLists.txt for debugging, and after running cmake I found.

In other words, <prefix>_INCLUDE_DIRS is not reliable because it could be empty on some system, and CMakeLists.txt should use <prefix>_FOUND to determine the existence of library.

[xinyazhang]

Further details: this behaviour of pkg-config is implemented at LN 802 -- 865 in pkg.c, where pkg-config removes any -I cflags if it's already in $PKG_CONFIG_SYSTEM_INCLUDE_PATH, $C_INCLUDE_PATH, or $CPLUS_INCLUDE_PATH

[v4hn]

In other words, _INCLUDE_DIRS is not reliable because it could be empty on some system, and CMakeLists.txt should use _FOUND to determine the existence of library.

You are right. Your initial description did not link to the respective code lines and checking the respective *CCD_FOUND variables is the correct way to check for successful detection.

This whole block seems to be a a hack for multiple package config names and could be avoided by just checking for the different package names sequentially.

Could you prepare a pull-request to fix it?

[xinyazhang]

Sure. I actually already have a dirty hack over this problem. A cleaner solution is on the way.

Sent from my iPhone

On Oct 8, 2020, at 4:49 AM, Michael Görner notifications@github.com wrote:

 In other words, _INCLUDE_DIRS is not reliable because it could be empty on some system, and CMakeLists.txt should use _FOUND to determine the existence of library.

You are right. Your initial description did not link to the respective code lines and checking the respective *CCD_FOUND variables is the correct way to check for successful detection.

This whole block seems to be a a hack for multiple package config names and could be avoided by just checking for the different package names sequentially.

Could you prepare a pull-request to fix it?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.