continued problems with a recent Phabricator Diff (libofx detection)

Jack ostroffjh at users.sourceforge.net
Tue Jan 2 16:06:22 UTC 2018


On 2018.01.02 03:47, Thomas Baumgart wrote:
> On Montag, 1. Januar 2018 18:05:55 CET Jack wrote:
[snip...]
First, to confirm, the intent is to build all importers if the  
libraries are available, as long as the user has not explicitly said  
not to do so.  However, after the first run of cmake, options will not  
be changed except explicitly by the user.

> 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).
Yes, this does make sense, even if it is a bit confusing at first.
> 
>> 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:
(I'll test again later.)
> 

> 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
what about d) LibOFX is not installed, user runs cmake w/  
-DENABLE_OFXIMPORTER=ON
   Am I correct this would generate an explicit error about libOFX not  
found?
> 
> 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
Yes.  Definitely.

Thanks for putting up with all the questions.

Jack


More information about the KMyMoney-devel mailing list