compile failure with git master

Tue Jan 2 07:49:58 UTC 2018

On Montag, 1. Januar 2018 17:32:22 CET Jack wrote:

> On 2018.01.01 06:25, Thomas Baumgart wrote:
> > On Sonntag, 31. Dezember 2017 13:00:27 CET Jack wrote:
> > > On 2017.12.31 11:42, Thomas Baumgart wrote:
> > > > On Sonntag, 31. Dezember 2017 11:33:42 CET Jack Ostroff wrote:
> [snip....]
> OK - the compile failure was fixed by D9586.
> 
> > Nope, please see https://phabricator.kde.org/D9584 which should bring
> > back the original behavior. Please feel free to test it as well.
> 
> I will test this shortly, but for me the problem is not with finding
> libofx.  It is that in the past, I don't believe I ever explicitly
> enabled ofx import in the cmake command - it was automatically enabled
> if libofx was found.  However, as I think about this, it is probably OK
> to NOT have ofx import enabled by default, since it is not needed for
> someone using aqbanking, and it would not make sense to make them
> explicitly disable it.  It does make more sense to require me to
> explicitly enable it if I want it.

I tackle this from the packager's perspective: I want to support as many 
environments as possible, and KMyMoney allows me to do so. Think of having the 
following packages (and they exist today):

- KMyMoney
- LibOFX
- AqBanking

Now as a user A I install KMyMoney and LibOFX and I should have OFX support. 
As user B I install the same KMyMoney package as user A together with 
AqBanking and I should have them working together. This requires the packager 
for KMyMoney to compile the package together with LibOFX-devel and AqBanking-
devel being present. I don't want him to add extra switches to cmake to get 
things built. However, for the user who builds from source and does only have 
LibOFX-devel installed, I don't want to have additional steps to disable 
AqBanking support in his build.

> However, I  still think we need to update the README.ofx file, which
> hasn't been changed since 2011.  It still says to ENABLE_LIBOFX and it
> seems now to be ENABLE_OFXIMPORTER.  We can also update the version
> numbers mentioned.  I'll just update the file and commit, unless
> someone thinks it requires a Phabricator Diff just for that one text
> file.

Yes, it needs to be updated, and I think there is no need to go through 
Phabricator for it unless you are unsure about the contents and want 
confirmation from the team.

> >> Anyway, I also had some moc related warnings on "make install" but
> >> we'll see if they also go away if I fix this problem.  In addition,
> >> "Generate API documentation with Doxygen" is now "yes" and I don't
> >> think it used to be, and I know I do not address it directly in my
> >> cmake command.
> > 
> > moc should not run during make install if you have done a make
> > beforehand.
> 
> I do not think they are moc failures during install, but warnings about
> moc files.  For example:
> [ 75%] Automatic MOC for target konlinetasks_sepa
> AutoMoc: Warning:
> "/local/data/jack/KDE/KMM/kmymoney-git/kmymoney/plugins/onlinetasks/sepa/sep
> aonlinetasksloader.cpp" The file includes the moc file
> "sepaonlinetasksloader.moc", but does not contain a Q_OBJECT or Q_GADGET
> macro.
>   I get the same warning 19 times.  I have no idea whether it is
> important or not, but I have not noticed any problem with running KMM
> even after getting those warnings on "make install."

This seems to be a general problem for others as well and of no harm: See 
https://gitlab.kitware.com/cmake/cmake/issues/17176 for details. So let's put 
this aside for now. Nothing we can do about other than waiting for a fix in 
cmake.

> >>> Strange.
> >>> https://build.kde.org/job/Extragear%20kmymoney%20kf5-qt5%20SUSEQt5.9/
> >>> shows no problems with a build from scratch. And the part you
> >>> mention is not optional.
> 
> I have no idea why two of us had the failure and Jenkins did not.
> Anyway, the patch fixes it for us - let's just hope it doesn't now
> break it for Jenkins or anyone else. :-)

Could be a more modern combination of cmake/make.  Jenkins is still happy ;)

> > I am certainly using different versions. That might have something to
> > do with it. I will take the patch provided by Alexandre and create a
> > phabricator diff and have you check it before I commit anything.
> 
> Given the patch in D9586, different versions should not make a
> difference, but we've all seen strange things happen.

Apparently, not this time. Glad we could solve this one.

-- 

Regards

Thomas Baumgart

https://www.telegram.org/       Telegram, the better WhatsApp
-------------------------------------------------------------
Software and cathedrals are much the same –
first we build them, then we pray. -- Sam Redwine, 1988
-------------------------------------------------------------
-------------- 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/0a2a2d4c/attachment.sig>