[OSX] Webkit.

David Reiser dbreiser at earthlink.net
Thu Sep 17 00:43:08 EDT 2009


On Sep 16, 2009, at 11:15 PM, John Ralls wrote:

>
> On Sep 16, 2009, at 1:44 PM, Phil Longstaff wrote:
>
>> On September 16, 2009 12:12:39 pm Derek Atkins wrote:
>>> True, but we can (and should) pick a particular version of Gtk  
>>> that we
>>> build against for 2.4 and just stick with it.  We could even
>>> theoretically pre-build the deps, store them as Zips, and just re- 
>>> use
>>> them in our build process (it would certainly make full builds  
>>> faster!)
>>>
>>> Honestly I dont think we need to keep rebuilding the deps over and  
>>> over
>>> and over.  We should build the deps once (well, until we get them
>>> working) and then re-use the (working) builds over and over....
>>
>> That would also let us be able to update dependency versions when  
>> we want,
>> rather than when the download version changes and the one we want  
>> is no longer
>> available (which has happened).
>>
>> I guess we'd need both 32-bit and 64-bit builds of each dependency  
>> for win32.
>> I don't know re macosx.
>
> There's no problem with this from the M$Win and OSX perspective. OSX  
> builds will have to stay 32-bit at least until I figure out how to  
> rewrite the mac-integration library with Cocoa instead of the  
> present Carbon. I don't see any real advantage to having a 64-bit  
> Gnucash anyway, and OSX at present will happily launch both 32-bit  
> and 64-bit apps. The only restriction is that plugins have to match  
> the architecture of the executable.
>
> From a jhbuild (i.e., Gtk-OSX) perspective, it makes most sense to  
> build the dependencies once and then update and rebuild just  
> Gnucash. Fortunately, this is trivial to set up.
>
> A problem arises with distributions, whether they're Linux, BSD, or  
> Fink and MacPorts on OSX. The maintainers of those distros want to  
> frequently update the versions of our dependencies. Their users  
> expect them to do so. From time to time there will be interface  
> changes (or worse, behavior changes without an interface change)  
> that will break our build. We do need to be able to find out about  
> them and react accordingly. Since Gnucash is reasonably popular,  
> perhaps we can rely on the distro maintainers to open tickets when  
> it happens. (Or perhaps not. I'm new here: What's the actual  
> experience been?)

I'm the current fink gnucash maintainer, and I'm reasonably active  
both here and in fink. I do generally ask here or in #gnucash if  
something  breaks on either a gnome component update or OS X change.  
I'd be happy to continue filing bugs and patches as things move forward.

Macports doesn't currently have a gnucash maintainer, though the core  
folks step in and patch bugs in the gnucash portfile as necessary.  
They provide a lot more flexibility for optional pieces of gnucash  
than I do, but macports doesn't expend as much effort as fink does in  
general to prevent ABI/API changes in dependencies causing gnucash  
breakage.

>
> That said, to avoid making ourselves crazy, we *should* pick  
> release  versions of all the dependencies for 2.3.x , record them in  
> README.dependencies, set up the buildbots to build them once, and  
> only build Gnucash itself nightly.

One dependency change to be aware of: aqbanking 4 stores its  
configuration files in a different directory (~/.aqbanking) than does  
aqbanking 3 (~./banking). There is no conversion utility available, so  
users will have to re-enter their user login data when aqbanking is  
upgraded from 3 to 4. The big plus for upgrading is that version 4 has  
some investment account handling capability. I'm finally just about  
ready to test that, so I'll find out if it makes sense to bump the  
fink gnucash dependency to the new version. I'm not familiar enough  
with German banking to know what the 3->4 upgrade does for them.

>
> Regards,
> John Ralls


Dave
--
David Reiser
dbreiser at earthlink.net






More information about the gnucash-devel mailing list