On Jul 31, 2007, at 9:51 AM, Erik Paulson wrote:
In Quill's case, we're at least part of the way to having a C++ classthat is abstract from any database. I doubt this actually works, but the idea would be that if HAVE_EXT_POSTGRES and HAVE_EXT_ORACLE are both NO,then all of Quill still compiles, it just doesn't do anything useful. Very few places would have to be wrapped in HAVE_EXT_ORACLE/POSTGRES.
Quill is a good example for all sorts of reasons...In this case, if you don't have either DB backend, there's no sense bloating our binaries with code that "doesn't do anything useful". It'd be better to just not compile that code at all if you have no intention (or ability) to use it.
Ideally...A) Each conditional feature knew what externals it depends on. Features can be enabled or disabled with --enable-<foo>. We have reasonable defaults for what features are enabled if you don't specify anything to configure.
B) Each external could be --with-<foo> to supply a path, --without- <foo> to disable, or left off to use the default external in the externals directory.
C) configure would be smart enough to figure out if you requested features that need externals that you don't have, and blow up in your face about it.
D) otherwise, we only check for and build externals that are required by the currently enabled features for a given build. so, if you say "--disable-quill" and quill is the only thing that introduces a pgsql or oracle dependency, we just assume --without-pgsql and --without- oracle and don't build either external.
... -Derek