Derek Atkins wrote: >Mark Johnson <[EMAIL PROTECTED]> writes: > > > >>A new version of libgda has been released. It is 2.99.2. They have >>bumped the ABI version to 3.0. Consequently, libgda-2.0.pc is now >>libgda-3.0.pc. Therefore, after upgrading to libgda 2.99.2, the build >>in gda-dev branch fails. >> >> > >Was there even ever a libgda-2.0 stable release?? > > No, it looks like they just bumped the version from 1.99.1 to 2.99.2. There's probably more to it than that. Anyway, 1.99/2.0 appears to be history, and it will be 2.99/3.0 from here on.
> > >>Further feedback on gda-dev: >>configure did not fail when libgda-2.0.pc was not present. The >>configure.in should be updated to have an option to enable/disable this >>backend (like the --enable-sql option for postgresql). When the libgda >>is not present and the option is enabled, the configure should fail >>rather than the build. >> >> > >I guess it depends if GDA is going to be optional or not. We could >do something like what libofx does in terms of AC_MSG_WARN vs >AC_MSG_ERROR > > What I'm looking at is using AC_ARG_ENABLE to make a --disable-gda argument, so that for the gda-dev branch (at least for now) building the gda backend would be the default. This would replace the current argument which takes a path to the libgda-2.0.pc file. Shouldn't that be set in the PKG_CONFIG_PATH environment variable? What I don't understand is: When I pass --disable-gda, how does make know not to build that backend? For example, I don't pass --enable-sql, and the postgres backend is not built. (Right? It's got to be right; I don't have postgres installed on some machines where I've built gnucash.) But I can't seem to find how that information is passed from configure to the build process. >>I've attached a trivial (stop-gap) patch to illustrate what I am >>currently testing (i.e. simply to see if gnucash gda-dev builds with >>libgda-3.0). This is not what I am suggesting as the mod to >>configure.in. I'll work on that later. >> >>So far gnucash gda-dev is still building, which is a good sign, but it >>will be morning before I know if the build succeeded. >> >> > >If it works with either, do we want to allow either? Perhaps test for >-3.0 and if it's not there fall back to -2.0? Definitely interested >in hearing your results. > > > The build succeeded with the above stop-gap. I was able to open an existing db, and my transaction and accounts were there. Now, to really fix configure.in.... If anyone is interested, libgnomedb was also bumped up to 2.99. It requires gtk+ version 2.10.x, but their configure tests for an older version. (http://bugzilla.gnome.org/show_bug.cgi?id=389821) Mark _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
