[Marble-devel] What's new in KReport & KProperty & Predicate

Jaroslaw Staniek staniek at kde.org
Tue May 26 11:48:51 UTC 2015

BTW, Dennis:

Running cmake fails:

"CMake Error at CMakeLists.txt:321 (ADD_CUSTOM_TARGET):
  add_custom_target cannot create target "uninstall" because another
  with the same name already exists.  The existing target is a custom
  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_COMMAND}" -P "${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
+    #"${CMAKE_COMMAND}" -P "${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")


On 24 May 2015 at 11:30, Dennis Nienhüser <earthwings at gentoo.org> wrote:
> Hi Jaroslaw,
> Am 24.05.2015 00:10, schrieb Jaroslaw Staniek:
>> On 23 May 2015 at 15:39, Dennis Nienhüser <earthwings at 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

regards, Jaroslaw Staniek

: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

More information about the Marble-devel mailing list