Tom Lane writes:
> It would probably be a good idea to add another configure test to see
> whether class "string" is actually available, and disable building
> libpq++ if not. (We shouldn't simply kill libpq++ if the "include
> <string>" test fails, since older C++ installations may have class
> string in <string.h>. But if we can't find a header that defines class
> string at all, then libpq++ is definitely going to fall over.)
As a short term solution, why not, it's already bad enough. But for the
future I'd like to suggest the adoption of a different principle: It's not
acceptable for parts of the tree to not be built based on the results of
configure tests. There are several reasons for that, the first and
foremost being that a configure script is not interactive. Users shouldn't
be required to monitor what flies by or, worse yet, deduce from cryptic
messages that stuff isn't going to be build at all. This is an incredible
can of worms for a package that interfaces to so many other software. For
the benefit of both users and maintainers, a configure run with the same
options must produce an installation that behaves the same on any
machine. I know this is slightly impractical in some cases, but only in
some.
In this particular case what ought to happen is this: When the package is
being configured to build libpq++ (whether by default or explicitly) and
some necessary feature is missing then the build must fail hard. Silently
ignoring build errors as has been suggested is equally problematic because
users will not sit in front of their terminal for 20 minutes and scan the
make output. In practice it might be preferrable to not make the C++ build
default because it's really no more special than say the Perl or Tcl
interface and exposes people that don't really care/know about C++ to
gratuitous problems. Also, the current configure run will fail if you
don't have a C++ compiler at all.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
