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 -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
