2011/3/7 Laszlo Papp <djsz...@archlinux.us>: > Any progress on it ?
Nope. I won't be very responsive this week. > One more information, this n900-devel image uses > internally qemu and I am not sure that can cause any issue for the > build system. I don't like I said I'm not that experienced with cross-compiling env. > That is also interesting why the debian packaging worked just fine in > the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt then those: set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include CACHE PATH "The subdirectory relative to the install prefix where header files will be installed.") set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX} CACHE PATH "The subdirectory relative to the install prefix where libraries will be installed.") set(SHARE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/share CACHE PATH "The subdiractory relative to the install prefix where data and other files will be installed.") are not a good idea because after that you use xxxx_INSTALL_DIR as DESTINATIOn of your INSTALL(...) command which makes it use an ABSOLUTE_INSTALL PATH. you shouldn't use " ${CMAKE_INSTALL_PREFIX}/share " but "share" which would make it a relative path. Is there any reason you use absolute destination path. (this is probably not the culprit but this doesn't help either). I'll try to examine the problem more in detail tomorrow. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
