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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
