[OSX] Webkit.

[John Ralls]

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

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.

Regards,
John Ralls