Re: AppImage KMyMoney ?

[Jack]

On 2016.11.05 06:01, Edgar Alwers wrote:
As the new KMyMoney version for KF5 and Qt5 is "on the way" , would  
it not be a good idea, to provide this version also as an "AppImage"  
one ? Big projects like Digikam are going this way already (  
https://drive.google.com/open?id=0BzeiVr-byqt5SUZRMGtWa3VCUDg )


See also  "https://en.wikipedia.org/wiki/AppImage";

The KF5/Plasma system is actually not the easiest one to handle and  
the compilation of the new KMM does actually not function for me.  
Perhaps it would be a good idea to deliver an application that  runs  
without installation and can be always the actual version,   
independent from distributors


Please consider.

Edgar Alwers


I suggest filing a "wishlist" item at bugs.kde.org, so it doesn't get  
forgotten.  It's not a bad idea, but all current developer effort is  
going to completing the port to KDE Frameworks.  (I've cc'd the  
developer list, since I suspect any further discussion would happen  
there.)


I actually see on potentially good use for this in the short run.  An  
AppImage of 4.8 would let folks upgrade the rest of their system to  
Frameworks before the porting of KMyMoney is complete, but still use  
the working 4.8.  A lot of effort has certainly been spent on allowing  
both versions to exist on the same system at the same time.


The only potential negative I see is that I would guess an AppImage  
file for an application would be significantly larger than a standard  
distribution package, since it contains not just the application  
itself, but all dependencies.  It probably doesn't matter for one or  
two programs, but it might add up if you used it for many of them.


Does anyone on the list have any experience creating an AppImage file?

Jack

Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5

[Christian David]

Hi Ralf,

I still do not like this. The reason is that this just fixes the symptom, not 
the problem. With these changes we make a huge technical dept. Exept for 
version 4.8 we solved nearly all problems mentioned here already. So all 
changes are only a workaround to enable coinstallablity with a 5 years old 
release (which got perfectly replaced by alkimia 5).

Also adding the version of Qt – a third party library – to the library sounds 
really strange to me. I am sure this will cause more issues in future.

Regarding packaging; if there is really a fine grained configuration needed,  
there are a lot of cmake variables like

CMAKE_SHARED_LIBRARY_SUFFIX [1]
LIBRARY_OUTPUT_PATH [2]
INCLUDEDIR [3]

and probably even more ECM variables to achive this. With them not a single 
line of alkimia has to be changed. The packager can tune everything just the 
way he wants to. This way, someone who just wants to compile alkimia does not 
need to learn our naming conventions.

I really want to get away from the idea to encode any kind of version in the 
library name.

Greetings
Christian


[1] 
https://cmake.org/cmake/help/v3.1/variable/CMAKE_SHARED_LIBRARY_SUFFIX.html
[2] https://cmake.org/cmake/help/v3.1/variable/LIBRARY_OUTPUT_PATH.html
[3] https://api.kde.org/ecm/kde-module/KDEInstallDirs.html?highlight=includedir

P.S.:
The code
> if(QT4_FOUND)
>find_package(LibAalkimia4)
>if(NOT LIBALKIMIA4_FOUND)
>   find_package(LibAalkimia)
>endif()
> else()
>find_package(LibAalkimia5)
> endif()
> 
> if(QT4_FOUND)
>set(QT_SLOT 4)
> else()
>set(QT_SLOT 5)
> endif()
> 
> find_package(LibAalkimia${QT_SLOT})
> ...
> 
> |add_executable( ...) target_link_libraries(
> Alkimia::alkimia)

is way to long. find_package and the config scripts have the task to take such 
burdens of the package user. Probably the last line has to be changed from 
Alkimia::alkimia to Alkimia5::alkimia or so, too.


Am Mittwoch, 2. November 2016, 19:35:49 schrieb Ralf Habacker:
> Am 01.11.2016 um 00:05 schrieb Jack:
> > For Gentoo, if two versions are coinstallable, they get assigned to
> > different "slots" and in this case, I think the slot number would
> > easily correspond to the qt version (4 or 5) to align with other qt
> > and kde packages.  Also, as Gentoo is a source based distro, they
> > really cannot install any files with the same name, so the base
> > libalkimia.so should go to libalkimia4.so and libalkimia5.so.  (One of
> > them could stay libalkimia.so, but why not make things consistent if
> > were changing that much anyway?)
> 
> Collecting all requirements we get the following installation path layout:
> 
> Alikima 6.0.90 Qt4: [on a x86_64 system using /usr/local install prefix]
> -- Installing: /usr/local/lib64/libalkimia4.so.6.0.90
> -- Installing: /usr/local/lib64/libalkimia4.so.6
> -- Installing: /usr/local/lib64/libalkimia4.so
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Targets.cmake --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Targets-noconfig.cmake --
> Installing: /usr/local/include/alkimia4-6.0/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia4-6.0/alkimia/alk_export.h
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4Config.cmake [1] --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia4-6.0/LibAlkimia4ConfigVersion.cmake --
> Installing: /usr/local/lib64/cmake/LibAlkimia4-6.0/FindGMP.cmake --
> Installing: /usr/local/lib64/pkgconfig/libalkimia4.pc [2]
> 
> [1] with LIBALKIMIA4_INCLUDE_DIR=${PACKAGE_PREFIX_DIR}/include/alkimia4-6.0/
> and LIBALKIMIA4_LIBRARIES=${PACKAGE_PREFIX_DIR}/lib64/libalkimia4.so.6.0.90
> [2] with includedir=include/alkimia4-6.0 and Libs:-lalkimia4
> 
> Alkimia 6.0.90 Qt5:  [on a x86_64 system using /usr/local install prefix]
> -- Installing: /usr/local/lib64/libalkimia5.so.6.0.90
> -- Installing: /usr/local/lib64/libalkimia5.so.6
> -- Installing: /usr/local/lib64/libalkimia5.so
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Targets.cmake --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Targets-noconfig.cmake --
> Installing: /usr/local/include/alkimia5-6.0/alkimia/alkvalue.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alkquoteitem.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alkcompany.h
> -- Installing: /usr/local/include/alkimia5-6.0/alkimia/alk_export.h
> -- Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5Config.cmake [1] --
> Installing:
> /usr/local/lib64/cmake/LibAlkimia5-6.0/LibAlkimia5ConfigVersion.cmake --
> Installing: /usr/local/lib64/cmake/LibAlkimia5-6.0/FindGMP.cmake --
> Installing: /usr/local/lib64/pkgconfig/libalkimia5.pc [2]
> 
> [1] with LIBALKIMIA5_INCLUDE_DIR=${PACKAGE_PREFIX_DIR}/include/alkimia5-6.0/
> and LIBALKIMIA5_LIBRARIES=${PACKAGE_PREFIX_DIR}/li