Yes, I had KDE_SKIP_UNINSTALL_TARGET set to prevent the KDE (not Marble)
uninstall target creation, but this was only picked up after the second
cmake run. It's fixed now with commit cd15e0c.
Regards,
Dennis
Am 26.05.2015 13:48, schrieb Jaroslaw Staniek:
BTW, Dennis:
Running cmake fails:
"cmake -DCMAKE_INSTALL_PREFIX=~/dev/inst5 -DBUILD_MARBLE_EXAMPLES=YES
-DBUILD_MARBLE_TOOLS=YES -DCMAKE_BUILD_TYPE=Debug -DQT5BUILD=ON
../../src/marble"
"CMake Error at CMakeLists.txt:321 (ADD_CUSTOM_TARGET):
add_custom_target cannot create target "uninstall" because another
target
with the same name already exists. The existing target is a custom
target
created in source directory
"
I had to commend out two lines:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e24e37b..00c6868 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -318,8 +318,8 @@ CONFIGURE_FILE(
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
IMMEDIATE @ONLY)
-ADD_CUSTOM_TARGET(uninstall
- "${CMAKE_COMMAND}" -P
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
+#ADD_CUSTOM_TARGET(uninstall
+ #"${CMAKE_COMMAND}" -P
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
include(MarbleCPackOptions)
On 24 May 2015 at 11:30, Dennis Nienhüser <earthwi...@gentoo.org>
wrote:
Hi Jaroslaw,
Am 24.05.2015 00:10, schrieb Jaroslaw Staniek:
On 23 May 2015 at 15:39, Dennis Nienhüser <earthwi...@gentoo.org>
wrote:
Hi Jaroslaw,
Am 23.05.2015 00:43, schrieb Jaroslaw Staniek:
The only thing I noticed: on install it ignores that lib64/ is the
right destination on my x86-64:
-- Installing:
/home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.0.21.20
-- Up-to-date: /home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.22
-- Up-to-date: /home/jarek/dev/inst5/lib/libmarblewidget-qt5.so
-- Removed runtime path from
"/home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.0.21.20"
I had to cd lib/; cp -R * ../lib64/.
The RUNPATH is OK though, e.g.:
% readelf -d `which marble` | grep RUN
0x000000000000001d (RUNPATH) Library runpath:
[/home/jarek/dev/inst5/lib64]
when running the same here I don't have a RUNPATH entry. I'm wondering
whether our software stack (cmake, kf5, ecm) behaves differently or
whether
something in your build environment is different to mine. Are you
building
Marble standalone or via some wrapper that compiles multiple projects
at the
same time?
I can reproduce a RUNPATH entry when I add --enable-new-dtags to the
linker
flags (like KDECompilerSettings.cmake does), however it does not end
up with
a 64 suffix. I'm working on a x86_64 as well. If I pass
-DLIB_SUFFIX=64 as
another cmake option, I end up with the same RUNPATH entry as you,
however
it does install correctly to lib64. LIB_SUFFIX is a cmake option added
by
Marble.
My goal for now is to understand why things end up differently on our
systems, and then fix it to reach a consistent installation. One quick
fix
would be to use ECM globally in Marble, with the nice side-effect of
reducing our CMakeLists.txt complexity further. This needs to be
discussed
in the Marble community first however as ECM would become a mandatory
build-time dependency (Marble does not depend on KDE software so far,
just
Qt. Maybe we can blur that a bit now that KF5 is there as 'thin Qt
addons').
The alternative is to mimick KDE behavior manually in our cmake files,
which
is prone to end up with subtle differences like the above.
Regards,
Dennis
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
