[Kmymoney-devel] KMyMoney on OSX

[Cristian Oneţ]

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).