First, the good news: I have reverted to libalkimia 4.3.2 and created a
successful gentoo ebuild for 4.8 git head. I have successfully
remapped my Chase credit card usingn the Client-UUID. Now, at least I
can catch up on actually tracking my finances separate from working on
all the below issues.
On 2016.10.22 17:20, Ralf Habacker wrote:
Am 22.10.2016 um 20:02 schrieb Jack:
> On 2016.10.17 02:44, Ralf Habacker wrote:
>> Am 17.10.2016 um 00:52 schrieb Jack:
Something Alan sent me made me look and think it might have been
because alkimia was compiled with qt5, but I'm no longer sure
about that.
alkimia >= 5.0.0 fetches Qt5 dependencies into a project using it.
You need to revert alkimia to version <= 4.3.2. Another option
would be to (re)add Qt4 support to recent alkimia.
>> Ralf
>>
I realized that converting libalkimit >= 5.0.0 to use QT4 is
probably not as good a solution as I was thinking, as it would be a
conversion, not an addition, so that version would still not be good
for the frameworks version of KMM.
yes
>
So, I figured I would installing 4.3.2 somewhere out of my main
tree, and point cmake for 4.8 git heat to that version. However,
nothing I have tried has worked - it keeps finding the version of
libalkimia from it's git head (under/usr) instead. Oddly, it looks
like CMakeLists.txt has a test and should fail for libalkimia >=
6.0.0 but it claims it finds 6.0.9 but is not failing. Is this a
cmake bug, or am I not understanding something?
I and Thomas already tried to fix that, but it looks to be complex,
because alkimia switched from 'module' to 'config' mode. See below
for a solution.
>
I have tried setting CMAKE_PREFIX_DIR (and several variations) both
as an environment variable and with -D, and I have tried setting
LibAlkimia_DIR, but cmake is either ignoring them, or not finding
what it wants. Is perhaps part of the problem that prior to 5.0.0,
libalkimia only produce a FindLibAlkimia.cmake and not and
....Config.cmake?
Also see below
>
For now, I will uninstall the more recent libalkimia from my main
tree and install the older version, but I'd prefer to have all the
frameworks related stuff in my main tree, and any remnant KDE4 stuff
that cannot coexist installed elsewhere. On that note, I don't know
if it is inherent to the alkimia install or to the gentoo ebuild
that the qt4/kde4 qt5/frameworks versions cannot be installed at the
same time, since several of the files have identical names in both.
This looks to be a regression of porting anything to Qt5 without
taking into account that stable versions may be maintained longer
than expected.
I don't know if I'd call it a regression, but it certainly causes some
problems. When I started working on compliling the frameworks version
of KMM, I kept all frameworks stuff separate from the KDE4 in my main
tree (/usr). Now that I have make most of my main tree frameworks
based, I'm finding more of these problems. I don't think KMM itself
can have both versions at once. I'll certainly test your version of
libalkimia. However, in the main kdelibs/frameworks, the big issue is
that the pim stuff can not have 4/frameworks both installed. Given
that KMM4 has a hard dep on pimlibs, now that I have 4.8 from git head
working in my main tree, I'll keep all my framework stuff separate -
although if I use your below to get both qt4 and qt5 libalkimia 6.0
installed, then only KMM itself will need to be separate.
> Am I just trying the impossible?
No, I just pushed a commit to a personal repo at
https://github.com/rhabacker/alkimia, which readd's Qt4 support to
latest version of alkimia. You can build and install alkimia side by
side to the Qt5 variant. You may try that. See the commit log how to
build alkimia in this way.
I'm not sure how soon I'll have time to try, but I will definitely look
at what you've done.
Thanks for all the effort.
Ralf
Jack
