Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
It currently says:
***
Disabling build of libpq++ because we cannot find class string in the
system's C++ header files.
***
Too cryptic for you?
I have a different take on the matter: it's not acceptable for a default
build of Postgres to fail hard because the local system's C++ compiler
is broken, libstdc++ is missing or incomplete, etc. There are too many
machines that fit that description and too few people using libpq++ to
justify treating libpq++ as an essential component.
Perhaps we could agree on a compromise that libpq++ ought not be built
at all unless specifically requested by a configure switch (eg,
"--with-libpq++"). If the user actually asked for it, then failing hard
is reasonable behavior. It's too late to make such a change for 7.0,
I think, but we could do it for 7.1.
> 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.
Right, I don't like that idea either.
> Also, the current configure run will fail if you
> don't have a C++ compiler at all.
Fail completely? I haven't tried that lately, but from the Autoconf
docs I'd expect it to set CXX=gcc and then all the C++ feature tests
would fail because gcc isn't there (or doesn't grok C++) --- which as
things currently stand would end in our deciding not to build libpq++.
Seems fairly reasonable. If configure actually falls over in that case
then we've blown it...
regards, tom lane
