This commit changes behavior such that if --disable-core-odbc-support
is provided we'll build without ODBC even if the libraries are there.
Previously we would always quietly build with ODBC support if it was
on the system.
Contrary to what was said in commit 72a804983, my 2012 commit
ffc8e81b7 did not affect the behavior of --disable-core-odbc-support.
We never recognized the flag as being different from not providing the
option at all.
What the commit did do was to cause us to fail loudly if
--enable-core-odbc-support was provided but the system libraries were
not there. This behavior is preserved.
(That commit also caused us to potentially run certain checks twice,
which this commit resolves.)
You can also now provide --enable-core-odbc-support=optional which has
the same effect as the default behavior.
FS-6173 --resolve
Thanks-to: James Le Cuirot <chewi@aura-online.co.uk>
...and rewrite entire block for better clarity of purpose.
We might want to look more closely at the AX_LIB_ODBC macro as well.
This amends commit 60c56109bc.
In commit ffc8e81b76, tc ensured that
configure would abort if libodbc was not found. However this resulted
in the library check being done twice, as well as rendering
--disable-core-odbc-support ineffective. If libodbc was found, it
would enable core ODBC support regardless. This fix ensures the check
is only done once or not at all if core ODBC support is explicitly
disabled.
Signed-off-by: Travis Cross <tc@traviscross.com>
We shouldn't be using pg_config to get build options for FS from
libpq. pg_config just tells us what was used to build postgresql, not
what we should use.
See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725007
Make this optional for now until we're comfortable it works
everywhere.
FS-5821 --resolve
Ken Rice
Michael Jerris
Travis Cross
James Le Cuirot
Anthony Minessale