[Kmymoney-devel] KMyMoney on OSX

[Michaël Lhomme]

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 ?

Regards,

-- 
Michaël Lhomme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kmymoney-devel/attachments/20091110/a3b774ca/attachment-0001.htm