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

[Dennis Nienhüser]

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 <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
>>