gda-dev; new libgda version
esodan at gmail.com
Thu Dec 28 23:31:10 EST 2006
> >>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
> 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.
AFAIK outside the backend code there's a file with the management to
load that backend when a URI is written, sorry I don't remember for
the moment but if you follow the GLADE3 support in gnomedb you'll see
dnl Checks for Glade3
GLADE3_MODULES="libgladeui-1.0 >= 3.0"
PKG_CHECK_MODULES(GLADE3, $GLADE3_MODULES, have_glade3=yes, have_glade3=no)
AM_CONDITIONAL(HAVE_GLADE3, test x"$have_glade3" = "xyes")
if test x"$have_glade3" = "xyes"
GLADE3_PIXMAP_DIR=`pkg-config --variable=pixmapdir glade-3`
GLADE3_MODULES_DIR=`pkg-config --variable=moduledir glade-3`
GLADE3_CATALOG_DIR=`pkg-config --variable=catalogdir glade-3`
then in Makefile.am in the backend you can do like in Makefile.am in
gnomedb for glade3:
SUBDIRS = \
Then if glade3 doesn't exist the gda's subdirectory will never be
compiled (like in glade3 for gnomedb).
> 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
I'll try to fix it when possible or talk with Vivien, please inform
this in gnomedb-devel list.
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
More information about the gnucash-devel