continued problems with a recent Phabricator Diff (libofx detection)

[Thomas Baumgart]

On Montag, 1. Januar 2018 18:05:55 CET Jack wrote:

> D9854 is supposed to fix libofx detection.
> 
> Using a clean build directory (parallel to the source directory) and
> git master (confirmed to include this patch) with the cmake command line
> 
> cmake -DCMAKE_BUILD_TYPE=Debug
> -DCMAKE_INSTALL_PREFIX=/home/jack/KDE/KMM/installframeworks
> -DLibAlkimia5_DIR=/home/jack/KDE/KMM/installframeworks/lib64/cmake/LibAlkimi
> a-6.0 ../kmymoney-git
> 
> the cmake output includes (trimmed)
> 
> -- Checking for module 'libofx>=0.9.4'
> --   Found libofx, version 0.9.11
> -- Found LibOfx:
> -- Performing Test LIBOFX_HAVE_CLIENTUID
> -- Performing Test LIBOFX_HAVE_CLIENTUID - Success
> ....
> OFX plugin:                              no
>    OFX supports CLIENTUID:                no
> 
> However, if I then do "ccmake ." in the build directory, I see
> 
> ENABLE_OFXIMPORTER               ON
> 
> and if I then type "c" (configure) I see
> 
> OFX plugin:                              yes
>     OFX supports CLIENTUID:                yes
> 
> so something still seems wrong to me.

The problem was the location of the definition of ENABLE_OFXIMPORTER in the 
CMakeLists.txt file. It needs to be located with the checks which it wasn't.

Also, the default of the setting is only used during the first run of cmake 
ever. Later on, it seems that one cannot change the setting programatically 
but only through user intervention (ccmake).

> At this point, I don't care whether the default should be yes or no for
> OFX plugin if it is not explicitly mentioned, but I do expect ccmake to
> show the same results and choices as per the immediately prior run of
> cmake.  Is there something strange going on, or am I misunderstanding
> something about cmake/ccmake?

The problem here is, that there are now two where there was one before. I 
changed the code (and committed that to master already) so that the initial 
run of cmake reflects what you suggest. Here's what happens in the various 
cases:

First run:
a) LibOFX not installed, user runs cmake w/o options:
   ENABLE_OFXIMPORTER is OFF, the importer will not be build
b) LibOFX is installed, user runs cmake w/o options:
   ENABLE_OFXIMPORTER is ON, the importer will be build
c) LibOFX is installed, user runs cmake w/ -DENABLE_OFXIMPORTER=OFF
   ENABLE_OFXIMPORTER is OFF, the importer will not be build

Secondary run after a) 
d) now LibOFX installed, user runs cmake w/o options:
   ENABLE_OFXIMPORTER is OFF, the importer will not be build
   this is identical to the situation after a)
e) now LibOFX is installed, user runs cmake w/ -DENABLE_OFXIMPORTER=ON
   ENABLE_OFXIMPORTER is ON, the importer will be build
   this is identical to the situation after b)

Secondary run after b)
f) now LibOFX uninstalled, user runs cmake w/o options:
   ENABLE_OFXIMPORTER is ON, the importer will be build (but fails)
g) LibOFX is uninstalled, user runs cmake w/ -DENABLE_OFXIMPORTER=OFF
   ENABLE_OFXIMPORTER is OFF, the importer will not be build


Running cmake w/ options is identical to using ccmake and switching the option 
with addition configuration and generation.

The setting of ENABLE_OFXIMPORTER and LIBOFX_FOUND are cached. That is the 
reason for f) to fail, since both conditions are true (from cmake perspective) 
but in reality they are not. Since this is a very unlikely case and only 
caused by developers I did not care about it too much.

The summary output is based on LIBOFX_FOUND and LIBOFX_HAVE_CLIENTUID and not 
ENABLE_OFXIMPORTER.

Hope that helps to update README.ofx

-- 

Regards

Thomas Baumgart

https://www.telegram.org/       Telegram, the better WhatsApp
-------------------------------------------------------------
We had joy, we had fun, we had Linux on our Sun -- anonymous source
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 846 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20180102/2c4dab74/attachment.sig>