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

[Jaroslaw Staniek]

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?

Hi Dennis,
I am building using the standalone cmake command I mentioned before.
No special flags, no editing of the CMakeCache.txt.

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

Yes I fell this is a good approach. For example Kexi will also benefit
from beling 'light' of dependencies and using KF5/ECM to achieve this
is a good reuse of our KDE resources. It is easier to contribute to,
say, ECM than to maintain the scripts that 'mimick' the original
behaviour.

Please let me know when the buildsystem is ready to test the stuff
with the ECM approach.

Thanks.

-- 
regards, Jaroslaw Staniek

KDE:
: 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
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek