[Kmymoney-devel] KMyMoney on OSX

[Cristian Oneţ]

2009/11/10 Michaël Lhomme <papylhomme at gmail.com>:
> On Tue, Nov 10, 2009 at 10:52 AM, Cristian Oneţ <onet.cristian at gmail.com>
> wrote:
>>
>> 2009/11/10 Michaël Lhomme <papylhomme at gmail.com>:
>> > Forward of a mail replied directly to Cristian instead of the list...
>> >
>> >
>> > On Mon, Nov 9, 2009 at 11:36 PM, Cristian Oneţ <onet.cristian at gmail.com>
>> > wrote:
>> >>
>> >> În data de Luni 09 Noiembrie 2009 23:35:17 Michaël Lhomme a scris:
>> >> > On Mon, Nov 9, 2009 at 3:33 PM, Michaël Lhomme <papylhomme at gmail.com>
>> >> > wrote:
>> >> > > On Mon, Nov 9, 2009 at 2:18 PM, Alvaro Soliverez
>> >> <asoliverez at gmail.com>wrote:
>> >> > >> On Mon, Nov 9, 2009 at 10:10 AM, Michaël Lhomme
>> >> <papylhomme at gmail.com>wrote:
>> >> > >>> Hello all,
>> >> > >>>
>> >> > >>> just to follow the original mail from Cristian about KMyMoney on
>> >> > >>> Windows, I would like to say I'm currently "using" it with Mac
>> >> > >>> OSX
>> >> > >>> 10.6
>> >> > >>> (only screens "Home", "Ledgers" and "Schedules").
>> >> > >>>
>> >> > >>> Regarding the AqBanking plugin, the version currently provided by
>> >> > >>> MacPorts seems to be too old (CMake complains about that). Is
>> >> > >>> there
>> >> > >>> anyone owning an OSX and using AqBanking with KMM (I never used
>> >> > >>> it
>> >> > >>> and
>> >> > >>> I'm not sure my bank is compatible, so it would be difficult for
>> >> > >>> me
>> >> > >>> to
>> >> > >>> test it)
>> >> > >>>
>> >> > >>> Right now a patch is used to compile successfully :
>> >> > >>> - OSX linker does'nt support --no-undefined
>> >> > >>> - there is a linkage problem with QtSQL (already fixed for the
>> >> > >>> Windows
>> >> > >>> port ?)
>> >> > >>
>> >> > >> Hello Michaël,
>> >> > >> can you create a patch for this?
>> >> > >>
>> >> > >> If these issues are platform-specific, it should be something
>> >> > >> like:
>> >> > >>
>> >> > >> #if MAC_OSX_compiler
>> >> > >>
>> >> > >> #endif
>> >> > >>
>> >> > >> I don't know the specific name, but it must be easy to check in
>> >> > >> similar
>> >> > >> KDE apps on Mac.
>> >> > >>
>> >> > >> What about the other views? Are you getting crashes or they are
>> >> > >> just
>> >> > >> unable to compile?
>> >> > >>
>> >> > >> Regards,
>> >> > >> Alvaro
>> >> > >
>> >> > > The patch is already done, with tests for the platform, but I can't
>> >> > > get
>> >> > > it at the moment (it is at home on my laptop). I'll upgrade my
>> >> > > working
>> >> > > copy with latest svn changes and send the patch tonight.
>> >> > >
>> >> > > About the other views, they seems to work, but I don't really
>> >> > > use/test
>> >> > > them, so I can't state they are working correctly.
>> >> > >
>> >> > > --
>> >> > > Michaël Lhomme
>> >> >
>> >> > Here is the patch to fix the problem with --no-undefined. The linkage
>> >> > issue
>> >> > with QtSql library was already fixed in latest SVN.
>> >> >
>> >> > I tested quickly the other basic views without problems. I didn't use
>> >> > Budgets and Investments so there are not tested. Reports are working
>> >> > well,
>> >> > including charts (from preset reports and old customized reports).
>> >> > However,
>> >> > updating the type of chart for an existing report lead to a crash.
>> >> >
>> >> > Finally I also encoutered a strange behavior on the Forecast view.
>> >> >  Scrolling control the scrollbars for tables (as usual) but also the
>> >> >  differents tabs, so when at the bottom of the table, if I keep
>> >> > scrolling,
>> >> >  the panel is updated with the previous tab (and the opposite if I
>> >> > scroll
>> >> >  up). I guess it's a (weird) feature of Qt on OSX. I will try to
>> >> >  investigate this ASAP as it's quite"disturbing" [literal translation
>> >> > from
>> >> >  french... ;)]
>> >> >
>> >> >
>> >> > Regards
>> >> >
>> >> Wouldn't the test 'IF (APPLE)' be more general instead of testing for
>> >> Darwin?
>> >>
>> >> --
>> >> Regards,
>> >>
>> >> Cristian Oneţ
>> >
>> > Indeed the test would be more generic using 'IF(APPLE)'. Extract from
>> > the
>> > CMake wiki :
>> >
>> > - APPLE
>> > is TRUE on Apple systems. Note this does not imply the system is Mac OS
>> > X,
>> > only that __APPLE__ is #defined in C/C++ header files. Obtain more
>> > specific
>> > system information via CMAKE_SYSTEM_VERSION, i.e.
>> > IF(${CMAKE_SYSTEM_NAME}
>> > MATCHES "Darwin"), then it's Mac OS X.
>> >
>> > I must admit I have no idea if one solution is better than the other.
>> > Find
>> > another way to detect linker's specificity maybe a good alternative
>> > (something like CMAKE_COMPILER_IS_GNUCC but for the linker)
>> If only 'the Mac OS X linker' (I don't know which is that) does not
>> recognize --no-undefined than the patch should be applied as you've
>> submitted it. I've just asked for a more general test thinking that
>> the linkers on all Apple platforms behave that way but if that's not
>> the case than we'll apply the patch as submitted. But on a second
>> thought maybe we should use --no-undefined only when using the GNU
>> linker or find a way to do this trough cmake (let cmake handle the
>> platform specific issue).
>
> For KDE, various linker flags are set in the file FindKDE4Internal.cmake.
> --no-undefined is used only for Linux, tested with "IF(CMAKE_SYSTEM_NAME
> MATCHES Linux)". For Mac systems, the test is "IF(APPLE)"
>
> The safest way may be to follow the KDE behavior ?
>
I agree.