Description of problem: cmake reports COLLADA_DOM_INCLUDE_DIRS is //include/collada-dom;//include/collada-dom/1.5 (note the lack of "usr") to projects which depend on collada-dom. Version-Release number of selected component (if applicable): collada-dom-devel-2.3.1-10.fc20.x86_64 How reproducible: Unknown Steps to Reproduce: 1. Start with a "minimal" installation of Fedora and install collada-dom-devel 2. Create a cmake project which finds collada-dom 3. message() the COLLADA_DOM_INCLUDE_DIRS to screen Actual results: COLLADA_DOM_INCLUDE_DIRS=//include/collada-dom;//include/collada-dom/1.5 Expected results: COLLADA_DOM_INCLUDE_DIRS=/usr/include/collada-dom;/usr/include/collada-dom/1.5 Additional info: Some more debug from collada_dom-config.cmake: At the beginning, CMAKE_CURRENT_LIST_FILE=/lib64/cmake/collada_dom/collada_dom-config.cmake, which I believe is the root of the problem. I'm not sure if this is actually a bug in collada-dom, but hopefully someone can move it in the right direction.
I just hit this in PCL's cmake, too. It is not specific to collada-dom at all. I'll try to narrow it down a little bit...
Looks like I need CMAKE_PREFIX_PATH=/usr in env or else cmake bases everything at / instead of /usr. This is a fedora minimal install I just did today.
CMAKE_PREFIX_PATH Path used for searching by FIND_XXX(), with appropriate suffixes added. Specifies a path which will be used by the FIND_XXX() commands. It contains the "base" directories, the FIND_XXX() commands append appropriate subdirectories to the base directories. So FIND_PROGRAM() adds /bin to each of the directories in the path, FIND_LIBRARY() appends /lib to each of the directories, and FIND_PATH() and FIND_FILE() append /include . By default it is empty, it is intended to be set by the project. See also CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH. Empty default is expected.
Fwiw, collada_dom-config.cmake.in contains this snippet: get_filename_component(_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_PREFIX "${_PREFIX}" PATH) get_filename_component(_PREFIX "${_PREFIX}" PATH) get_filename_component(COLLADA_DOM_ROOT_DIR "${_PREFIX}" PATH) is what's used to calculate its prefix value.
I saw that, and as I mentioned, when the config.cmake executes: CMAKE_CURRENT_LIST_FILE=/lib64/cmake/collada_dom/collada_dom-config.cmake so it ends up with _PREFIX=/ which is incorrect. The reason that I deduced that this was a cmake bug was that the script was executed from the wrong location. find_package() found it in /lib64/cmake instead of /usr/lib64/cmake. If this is intended behaviour in cmake, then that snippet needs to be changed to handle it, but since I hit the same problem in another package, it leads me to believe that this is a cmake issue. Hopefully the cmake folks are listening and can shed some light on this. All that I'm saying about the CMAKE_PREFIX_PATH is that it is the only way I can get cmake to find the config.cmake in the CORRECT location, instead of in /lib64/cmake.
collada_dom-config.cmake needs to not calculate paths during dependent cmake runs, but rather set them according to where they are being installed at collada-dom build/install time.
Thanks for clearing this up, Orion. I see now that the snippet is incorrect. Do you have any idea why the system is finding the config.cmake in this way to begin with? I know it doesn't seem to have anything to do with my $PATH this time around, but beyond that, I can't figure out why this installation of Fedora is doing things differently... My CMAKE_SYSTEM_PREFIX_PATH=/usr/local;/usr;/;/usr;/usr/local which seems to be the norm, so that can't be the root cause... I'd like to know how many packages this quirk affects. The only other one I know for sure is pcl, so I'll loop rmattes in on this bug. So just to clarify, the repro for this bug is to create a cmake project, and try to find_package() collada_dom (or pcl) with -DCMAKE_PREFIX_PATH=/ Thanks all, --scott
It's likely getting confused due to https://fedoraproject.org/wiki/Features/UsrMove
Looks like one possible fix is to use REALPATH option of get_filename_component, to resolve symlinks per: http://www.cmake.org/cmake/help/v2.8.8/cmake.html
Thanks for adding me in Scott, I think that the code that this patch[1] tries to fix is the root of the problem in pcl. To fix it, I'm just going to patch it to stop playing games with relative directories and use CMAKE_INSTALL_PREFIX directly as the PCL_ROOT when PCLConfig.cmake is generated. This should be OK as our pcl is installed system-wide, if someone has a private build of pcl they want to reference they can override the CMake detection paths to discover the local PCLConfig.cmake. I thought I had made that change already, but I think the fix is in the pcl-1.7.1 update I'm working on (and will try to assign higher priority to now.) [1] http://pkgs.fedoraproject.org/cgit/pcl.git/tree/pcl-1.7.0-fedora.patch
PCL is fixed with the updates to 1.7.1
Fedora moved its bin and libs to /usr. If /sbin:/bin is included in the PATH environment variable CMake adds / as a search path. As /usr/lib64 can be reached via /lib64 (not tested on x86 arch) CMake may get confused when trying to determine PREFIX paths (depending on how they are resolved in its <PKG_NAME>Config.cmake) and cause some packages to fail when compiling. To avoid this behavior remove references to /bin and /sbin from $PATH. After that Cmake should work as expected. I'm debugging CMake to figure out whether this is really a bug (not sure by now). -- Jonatan
Cmake bug filled regarding this (https://bugzilla.redhat.com/show_bug.cgi?id=1131949).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is still a problem in Fedora 21. Any chance someone can take a look?
collada-dom-2.4.3-6.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/collada-dom-2.4.3-6.fc22
collada-dom-2.4.3-5.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/collada-dom-2.4.3-5.fc21
Thanks to everyone who has been helping with this. I've submitted a fix where the path is explicitly substituted at build time, and I've also sent the patch upstream [1]. Could you test if the submitted update indeed fixes the issue? [1] https://github.com/rdiankov/collada-dom/pull/15
collada-dom-2.4.3-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/collada-dom-2.4.3-3.fc20
Package collada-dom-2.4.3-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing collada-dom-2.4.3-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8125/collada-dom-2.4.3-3.fc20 then log in and leave karma (feedback).
collada-dom-2.4.3-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
collada-dom-2.4.3-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
collada-dom-2.4.3-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.