[CMake] CPack and RPM packages

[Eric Noulard]

2011/3/7 Laszlo Papp <djszapi at 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