[Kmymoney-devel] KMyMoney on OSX

[Alvaro Soliverez]

On Tue, Nov 10, 2009 at 7:36 AM, Cristian Oneţ <onet.cristian at gmail.com>wrote:

> 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.
>
> I agree. We should follow KDE's behavior for this kind of stuff.
Can anyone test this patch and confirm it works?
Just to make sure nothing is missing.

Regards,
Alvaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kmymoney-devel/attachments/20091110/f5bb96e3/attachment.htm